SEP Proposal: Bidirectional Tool Calls in Model Context Protocol
Summary
Currently, the ModelContextProtocol (MCP) is designed as a one-way protocol, where the agent (model) can only call external tools through the MCP client to the MCP server.
This proposal extends the protocol to support bidirectional communication: the MCP server can proactively call tools on the agent through the client.
Motivation
Many real-world use cases require the server to proactively interact with the agent, for example:
• The server detects important events and needs to notify the agent.
• Building real-time flows where the agent reacts to triggers from the server.
• Supporting more flexible tool chaining workflows.
Supporting only one-way communication limits the ability to develop real-time, event-driven systems or orchestrate complex multi-agent workflows.
Proposal
• Extend the MCP client to support a call_tool_on_agent or reverse_call_tool method.
• Allow the server to initiate tool calls back to the agent through the client.
• The bidirectional communication flow is clearly declared during the handshake via capabilities such as allow_server_calls.
• The agent can control which tools can be called by the server.
Describe alternatives you’ve considered
• Using separate WebSocket or pub/sub channels for the server to send data to the agent, but this creates multiple layers of communication complexity.
• Having the agent poll the server periodically, which introduces unnecessary latency.
Both alternatives are workarounds and not ideal compared to extending MCP directly.
Security Considerations
I acknowledge that this proposal introduces significant security challenges since the server can proactively call actions on the agent. However, this unlocks greater potential for the MCP server in scenarios where the agent needs to respond to programmed logic.
Some mechanisms to ensure security:
• Server-to-agent communication is only enabled when explicitly declared during the handshake (allow_server_calls).
• The agent retains the right to reject or filter which tools can be invoked by the server.
• The server can be restricted to only call specific whitelisted tools.
Real-world Use Cases
Some practical scenarios where bidirectional communication between the MCP server and agent is especially useful:
1. Programmatically Inject Prompts
In many systems, it is impractical to include all instructions or system information in a single prompt because:
• The prompt becomes too long, and the model may ignore or process it ineffectively.
• The prompt needs to be flexibly adjusted according to real-time circumstances.
With server → agent communication:
• The agent can ask the server for additional prompts.
• The MCP server can inject prompts or memory dynamically at runtime.
• The protocol will support more controlled prompt composition by the model.
2. Dynamic Memory Injection
Beyond prompts, the MCP server can provide short-term or long-term memory segments:
• For example, during a chat session, the agent can be updated with temporary information from the server like session state or history without needing to embed everything in the initial prompt.
3. Contextual Prompt Composition
The agent can proactively query the server for additional context, reducing token load and improving inference efficiency.
Additional Context
Extending MCP to support bidirectional communication will:
• Make MCP more flexible in real-time, orchestration, and complex AI agent applications.
• Simplify system architecture by keeping all communication within a unified protocol.
⸻
SEP Proposal: Bidirectional Tool Calls in Model Context Protocol
Summary
Currently, the ModelContextProtocol (MCP) is designed as a one-way protocol, where the agent (model) can only call external tools through the MCP client to the MCP server.
This proposal extends the protocol to support bidirectional communication: the MCP server can proactively call tools on the agent through the client.
Motivation
Many real-world use cases require the server to proactively interact with the agent, for example:
• The server detects important events and needs to notify the agent.
• Building real-time flows where the agent reacts to triggers from the server.
• Supporting more flexible tool chaining workflows.
Supporting only one-way communication limits the ability to develop real-time, event-driven systems or orchestrate complex multi-agent workflows.
Proposal
• Extend the MCP client to support a call_tool_on_agent or reverse_call_tool method.
• Allow the server to initiate tool calls back to the agent through the client.
• The bidirectional communication flow is clearly declared during the handshake via capabilities such as allow_server_calls.
• The agent can control which tools can be called by the server.
Describe alternatives you’ve considered
• Using separate WebSocket or pub/sub channels for the server to send data to the agent, but this creates multiple layers of communication complexity.
• Having the agent poll the server periodically, which introduces unnecessary latency.
Both alternatives are workarounds and not ideal compared to extending MCP directly.
Security Considerations
I acknowledge that this proposal introduces significant security challenges since the server can proactively call actions on the agent. However, this unlocks greater potential for the MCP server in scenarios where the agent needs to respond to programmed logic.
Some mechanisms to ensure security:
• Server-to-agent communication is only enabled when explicitly declared during the handshake (allow_server_calls).
• The agent retains the right to reject or filter which tools can be invoked by the server.
• The server can be restricted to only call specific whitelisted tools.
Real-world Use Cases
Some practical scenarios where bidirectional communication between the MCP server and agent is especially useful:
1. Programmatically Inject Prompts
In many systems, it is impractical to include all instructions or system information in a single prompt because:
With server → agent communication:
• The agent can ask the server for additional prompts.
• The MCP server can inject prompts or memory dynamically at runtime.
• The protocol will support more controlled prompt composition by the model.
Beyond prompts, the MCP server can provide short-term or long-term memory segments:
The agent can proactively query the server for additional context, reducing token load and improving inference efficiency.
Additional Context
Extending MCP to support bidirectional communication will:
• Make MCP more flexible in real-time, orchestration, and complex AI agent applications.
• Simplify system architecture by keeping all communication within a unified protocol.
⸻