Supporting callbacks with HTTP transport

[leo237]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Problem

Today, MCP Clients have to keep a connection open with an MCP server to facilitate communication between them. However, for asynchronous workloads where tools can take a long time to complete a task, maintaining the HTTP connection between client and server is often unnecessary and resource-intensive. With support for session management, this is mitigated to a great extent – clients can disconnect and poll the server intermittently to get the status. However, this polling approach still leads to inefficient resource utilization and can increase the network load (especially for MCP Clients & Servers running at scale using HTTP transport layer). This problem is further exacerbated in a multi-tenant MCP server.

Idea

Instead of clients having to pro-actively poll the server for updates or maintain an open connection with a server, the MCP protocol should (optionally) support messaging from server to client through callbacks on the HTTP transport

There are several benefits of introducing callbacks:

1. Efficient MCP client utilization by eliminating continuous polling, allowing the system to scale more effectively.
2. Allow developers to build event driven architectures. This allows for faster event processing and response times thus improving the user experience
3. Lower MCP server load and reduced network usage in a multi-tenant system, making the system more cost-effective and scalable.
4. Flexible client implementations: Clients that require higher durability and fault tolerance can optionally integrate a message queue to store incoming callback messages. This way, even if the client is temporarily unavailable, the messages can be stored and processed later.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[leo237]

Opened a discussion in the specification repo : modelcontextprotocol/modelcontextprotocol#266