Interpretation of MCP transport protocol improvement proposal: From HTTP+SSE to "streamable HTTP"

Introduction

This Pull Request (#206) proposes a new transport protocol called " Streamable HTTP " to replace the HTTP+SSE transport currently used by MCP (Model Context Protocol). This is an important technical improvement that aims to address some key limitations of the existing transport while retaining its advantages.

Address: https://github.com/modelcontextprotocol/specification/pull/206

Major changes

Compared to the current HTTP+SSE transport, the new proposal makes the following changes:

1. 1. Removed /sse Endpoints
2. 2. All client→server messages go through /message(or similar) endpoint transport
3. 3. All client→server requests can be upgraded to SSE by the server for sending notifications/requests
4. 4. The server may choose to establish a session ID to maintain state
5. 5. The client can /message Send an empty GET request to initialize the SSE stream

This approach is backwards compatible with implementations and allows the server to run completely stateless if desired.

Problems solved

The current HTTP+SSE transport has the following limitations:

• • No support for recoverability
• • Requires the server to maintain a high-availability persistent connection
• • Server messages can only be delivered via SSE

Advantages of the new solution

Support for stateless servers  - no longer needing long connections for high availability Pure HTTP implementation  - MCP can be implemented on regular HTTP servers, does not necessarily require SSE infrastructure Compatibility  - because it is "just HTTP", ensure compatibility with middleware and infrastructure Backward compatibility  - this is a gradual evolution of current transports Flexible upgrade path  - servers can choose to use SSE for streaming responses when needed

Example usage scenarios

Stateless Server

The proposal supports a completely stateless server implementation without the need to support persistent connections:

1. 1. Always confirm initialization (but no state needs to be preserved)
2. 2. For any incoming ToolListRequest Use a single JSON-RPC response
3. 3. Processing CallToolRequest Execute the tool, wait for completion, and then send a single CallToolResponse As HTTP response body

Stateless Server with Streaming

Even a completely stateless server that does not support persistent connections can still take advantage of streaming in this design:

1. 1. When receiving CallToolRequest When the server indicates that the response will be SSE
2. 2. The server starts executing the tool
3. 3. During the tool execution, the server sends any number of ProgressNotification
4. 4. After the tool is executed, the server sends CallToolResponse
5. 5. The server closes the SSE stream

Stateful Server

The implementation of a stateful server is very similar to what you have now, the main difference is that the server needs to generate a session ID, and the client needs to pass that ID back with each request. The server can use the session ID for sticky routing or to route messages on a message bus.

Why not use WebSocket?

The team discussed at length the possibility of using WebSocket as the primary remote transport, but ultimately decided not to do so for a number of reasons:

1. 1. For "RPC-style" use cases, WebSockets bring unnecessary operational and network overhead
2. 2. In the browser, it is not possible to attach header information to WebSocket (such as Authorization), and third-party libraries cannot implement WebSocket from scratch in the browser
3. 3. Only GET requests can be transparently upgraded to WebSocket, which means a two-step upgrade process is required on the POST endpoint, adding complexity and latency

The team also avoided including WebSocket as an additional option in the specification to limit the number of transports officially specified by MCP and avoid combination compatibility issues between clients and servers.

To Do

• • Move session ID responsibility to the server
• • Define the acceptable session ID space
• • Ensure middleware/WAF can introspect session ID
• • Make cancellation explicit
• • Requires centralized SSE GET for server→client requests and notifications
• • Convert resumability into a per-flow concept
• • Design a way to actively "end the session"
• • "If the client has an authentication token, it SHOULD include it in every MCP request"

Next Steps

• • Standardize support for JSON-RPC batching
• • Support streaming request body
• • Add recommendations about timeouts to the spec, and possibly a convention like "issuing progress notifications should reset the default timeout"

This proposal was formed based on extensive community discussion and feedback, demonstrating that MCP is actively evolving to meet the needs of a wider range of use cases.