MCP protocol may usher in a major update: introducing Streamable HTTP transmission
The latest changes in the MCP protocol usher in a new era of Streamable HTTP transmission.
Core content:
1. The introduction of the Streamable HTTP transmission mechanism and its major changes
2. The motivation for the update and the current problems of HTTP+SSE transmission
3. The advantages of the new protocol and application scenarios under different server types
Let's take a look at what MCP is through the picture above.
The MCP protocol has undergone a major update, introducing a new Streamable HTTP transport mechanism. This update addresses the key limitations of the current HTTP+SSE transport method while retaining its advantages. This improvement benefited from valuable feedback from Shopify, Pydantic, Cloudflare, LangChain, Vercel, Anthropic team and many members of the MCP community.
Major Changes
Compared with the current HTTP+SSE transmission, the new version has the following changes:
- Removed `/sse` endpoint
- All client → server messages go through the `/message` (or similar) endpoint
- All client → server requests can be upgraded to SSE by the server for sending notifications/requests
- The client provides a session ID in the request header; the server can monitor this ID as needed
- The client can initiate an SSE stream by making an empty GET request to the `/message` endpoint
This approach is backwards compatible with implementations and allows the server to run completely stateless if desired.
Update Motivation
The current remote MCP works through HTTP+SSE transmission, which has the following problems:
- No recovery support
-Requires the server to maintain a high availability long connection
-Server messages can only be delivered via SSE
Key Benefits
1. Stateless server feasibility : no longer need high availability long connection
2. Pure HTTP implementation : MCP can be implemented in a pure HTTP server without SSE support
3. Infrastructure compatibility : Just "plain HTTP", ensuring compatibility with middleware and infrastructure
4. Backward compatibility : incremental evolution of existing transport mechanisms
5. Flexible upgrade path : Servers can use SSE for streaming responses as needed
Application Scenario
Stateless Server
A completely stateless server may not support persistent connections:
-Always confirm initialization (no need to save state)
-Handles tool list requests via a single JSON-RPC response
-Execute the tool call request and return the response as HTTP response body after completion
Stateless Server with Streaming
Stateless servers can still take advantage of streaming:
- When receiving a tool call request, the server indicates that the response will use SSE
- Send progress notifications while executing tools
-After the tool is executed, it sends a response and closes the SSE stream
Stateful Server
Similar to the current implementation, but needs to handle the session ID header in order to route messages correctly in a horizontally scaled deployment.
Why not WebSocket?
The team discussed at length the possibility of using WebSocket as the primary remoting transport, but decided not to do so for the following reasons:
- Unnecessary operational and network overhead in "RPC-style" usage scenarios
- The browser cannot attach authorization and other header information
-Only GET requests can be transparently upgraded to WebSocket, requiring a complex two-step upgrade process
Summarize
This update brings greater flexibility and robustness to the MCP protocol, enabling it to adapt to a wider range of application scenarios. Although the HTTP-based solution is currently selected, other transmission methods such as WebSocket may still be explored in the future.
Through this technical upgrade, the MCP protocol will better meet the needs of modern application architecture and provide developers with more powerful and reliable message communication capabilities.
