[Enhancement Proposal] Agent Protocol Layer for DSPy for MCP and A2A Support

[Shashikant86]

What feature would you like to see?

Introduction

This proposal introduces a new Agent Protocol Layer in DSPy that provides a standardized framework for integrating various agent communication protocols. The layer will initially focus on Model Context Protocol (MCP) support while establishing extensible patterns for future protocols like Agent2Agent communication and many more those will emerge in the future.

Motivation

Everyone adopted MCP as standard these days (Google, OpenAI), why not DSPy?

Current Limitations

• DSPy currently lacks a unified framework for agent protocol integration like MCP and A2A which become defacto industry standard for now.
• The existing module is tool-focused rather than protocol-oriented, mainly rely on the ReAct for tool calling atm
• No standardized way to handle external agent communication protocols

Who is Affected

• Developers building multi-agent systems using MCP and other protocols
• Users requiring standardized context sharing between AI systems
• Organizations implementing agent-to-agent communication workflows

Evidence

The DSPy is modular and has better abstraction, which aligns with protocol layer requirements provided it technically fits into the DSPy ecosystem

Proposed Solution

Architecture Overview

Create a new protocol layer that extends DSPy's existing module system while leveraging the client architecture patterns from Core Components as mentioned below .. Just psudo code for now

Core Components

# dspy/protocols/base.py
class BaseProtocol(dspy.Module):
    """Base class for all agent protocols"""
    def __init__(self, protocol_config, **kwargs):
        super().__init__(**kwargs)
        self.protocol_config = protocol_config
        self.connection_manager = None
    
    def connect(self):
        raise NotImplementedError
    
    def disconnect(self):
        raise NotImplementedError
    
    def forward(self, **kwargs):
        raise NotImplementedError

# dspy/protocols/mcp/client.py
class MCPClient(BaseProtocol):
    def __init__(self, server_url, timeout=30, **kwargs):
        super().__init__({"type": "mcp", "server_url": server_url}, **kwargs)
        self.server_url = server_url
        self.timeout = timeout
        self.session = None
    
    def connect(self):
        # Synchronous MCP connection to work with DSPy's execution model
        self.session = self._create_mcp_session()
    
    def forward(self, context_request, **kwargs):
        if not self.session:
            self.connect()
        return self._handle_mcp_request(context_request, **kwargs)

# dspy/protocols/mcp/server.py
class MCPServer(BaseProtocol):
    def __init__(self, port, context_providers, **kwargs):
        super().__init__({"type": "mcp", "port": port}, **kwargs)
        self.port = port
        self.context_providers = context_providers
        self.server_instance = None
    
    def start_server(self):
        # Start MCP server with provided context providers
        pass

Integration with Existing Systems

The protocol layer will integrate with DSPy's async capabilitie to handle network communication while maintaining compatibility with the synchronous execution model.

Impact

Benefits

• Standardized Protocol Integration: Unified approach for adding new agent protocols like MCP, A2A, AG-UI and many more to emerge in the future.
• Future-Proof Architecture: Extensible design supporting multiple protocol types
• Backward Compatibility: No changes to existing DSPy programs and existing stuff still works.
• Performance: Leverages existing caching and parallelization infrastructure?

Trade-offs

• Increased Complexity: Additional abstraction layer to support multiple protocols and added maintenance.
• Network Dependencies: Protocols require external connectivity and will always have network dependencies unless mocked
• Synchronous Limitations: Network calls may block execution (but asyncify might help?)

Potential Implementation

• Base Protocol classes to support current protocols
• MCP Client implementation in the DSPy itself may be extent BaseLM
• MCP Server Implementation as DSPy Module
• Suport MCP Tool using existing Tools Support (Already documented) but make sure it works with al RM providers
• MCP Python SDK as dependency to make implementation easy.

Alternatives Considered

Alternative 1: Extend ReAct Module

• Pros: Builds on existing tool system as mentioned the one of the example in the docs/
• Cons: Limited to tool-based interactions, not protocol-oriented, Users have to write tools by hand which is cumbersome

Alternative 2: Separate Protocol Package or Plugin Architecture

• Pros: Independent development probably in separate repo.
• Cons: Doesn't leverage DSPy's optimization and module composition

Open Questions

Technical

1. Protocol Registration: How to discover protocols in DSPy?
2. State Management: How to handle protocol state across DSPy module compositions?
3. **Side Effect on Optimization **: How will protocol modules work with DSPy's optimisers? Does it even work?
4. Existing Module Support: Will Protocol layer support current DSPy modules like COT, Predict
5. Agent2Agent Protocol: Thinking far ahead but What abstractions are needed for peer-to-peer agent communication in future .
6. Multi-Protocol Support: If we get one protocol support working can users be able to use multiple protocols at the same time?

Would you like to contribute?

• Yes, I'd like to help implement this.
• No, I just want to request it.

Additional Context

No response

[chenmoneygithub]

Thanks for putting up the detailed feature request!

MCP and A2A which become defacto industry standard for now.

MCP is good and getting widely adopted, while I don't feel A2A has already gotten there. Furthermore, I don't have a good experience with A2A, but I am aware that A2A is still evolving.

MCP Client implementation in the DSPy itself may be extent BaseLM

I don't really get the benefit of introducing an extra wrapper of MCP inside DSPy over the simple integration between dspy.Tool and MCP. The purpose of MCP is a unified interface of tool access, so right now our approach is providing integration between dspy.Tool and MCP server, see code here. In general we want to avoid letting people learn extra knowledge in order to use tools like MCP. If your concern is that I can only use MCP via dspy.ReAct, it will be resolved by this PR: #8242.

One way to help us understand better about your motivation is putting up a reproducible notebook/colab/github repo that compares your proposal against the current DSPy MCP approach on a demo workflow, e.g., building an agent that can handle github PR reviews (using the official github MCP server).

[Shashikant86]

Thanks @chenmoneygithub for your response and appreciate your views and clarification on your understanding of A2A. You are 100% right that current react.py module nicely wraps the signatures and tools to craft the dynamic instructon for LLMs to predict the tool use. DSPy's Tool object is robust ecosystem to handle any tools passed to the system. However, looking at the current industry trends, other frameworks are choosing Protocol-First Design Vs Tool-First Design.

At the moment, based on the example in the docs and implementation in the react.py that you pointed, we are treating MCP is just yet another tool and want DSPy users to write DSPy MCP tools to fit into currently working ecosystem which is not bad idea from DSPy maintainers point of view. However, if you consider DSPy users, they have to write additional custom tools to fit into DSPy's Tools ecosystem. The whole point of the MCP is to avoid writing the custom tools that imposed by function calling approach and just use whatever available as service. IMO, current approach you are suggesting, defeats the purpose of MCP if we are asking users to write tools by hand. My understanding is protocol layer would recognize that MCP (and future protocols) have richer semantics than individual tools - they include context sharing, session management, capability negotiation, and standardized error handling that goes beyond what individual tool wrappers provide. I am not if optimisers would be able to reason about protocol layer patterns but hopefully there might be a way.

As other agents frameworks are adopting protocol layer approach (at least embedding MCP) in them and taking advantage of huge reliable list of MCP servers and making themselves future-proof and extendible. I was thinking the same for DSPy as it is already modular and extensible but I am not the decision maker. If you think, allowing users to write custom MCP tools is right approach then its up to you.

I totally understand your concern about added complexity, additional learning and additional overhead for project maintainer . However, the protocol layer could be designed as an optional enhancement - existing dspy.Tool usage would remain unchanged, but users who need protocol-level features could opt into the richer abstraction. I think, that's where industry is heading.

In order for me to implement protocol layer, I need to implement minimal protocol interface and test out with some simple agent, I already forked DSPy and will try (not sure when though). I can see that the approach mentioned in the Docs here seems to work without any issues but I think, its not how MCP should be used.

I would check, how CrewAI integrated MCP both as Tools and Server. Or OpenAI AgentSDK MCP integration .. And See if we can do something better here in DSPy.
Thanks again for taking time for responding to feature request.

[TomeHirata]

Thank you for the feature request and the detailed response.

if you consider DSPy users, they have to write additional custom tools to fit into DSPy's Tools ecosystem.

I'm not sure if this is true. Users should be able to use any MCP servers (such as community servers here) with dspy.ReAct. They define MCP client session with the standard mcp library and just convert the mcp tool definitions into DSPy tool style with Tool.from_mcp_tool. We understand that other agent libraries implement a wrapper for the server connection. But what are the additional benefits for users who are familiar with the official MCP client such as stdio_client? We wonder if the benefit users can get is worth the learning cost for the DSPy-specific MCP server session utils. So it would be great if you could describe the gains of the users from the additional layer when you work on the demo. Thank you.

[Shashikant86]

I spun up new package to enable the protocol-first agent design approach for DSPy. This approach skips the use React module like mentioned here and any other modules can be used here (Just returned the predictions at the moment). My plan is define the custom module that behaves in agentic manner.

I can see the extendibility of this approach not only limit to MCP but this can be scaled to A2A as well without much effort. Few other benefits I saw here Automatic connection management, Session state management, Future protocol extensibility etc. One thing, I need to figure out is how it can work with DSPy optimizers. I don't see any issue as long as there is gold examples and clearly defined metric but I need to verify.

I have tested this few examples with couple of agents including the PR review agent and seems to be working fine. I have a plan to test with more agents and more strategies. I am still working on it however posting the project here to get feedback from other contributors and code owners

Agenspy (Agentic DSPy)

https://github.com/SuperagenticAI/Agenspy

Let me know what you think? I would like to get more feedback from others including @okhat .. How can I include other code-owners?