MCP endpoints: SSE vs Streamable HTTP - chunhualiao/public-docs GitHub Wiki
The two MCP (Modal Context Protocol) endpoints you're referring to represent different transport mechanisms for handling server-client communication in AI model integrations. Note that while SSE was initially the standard, it has since been deprecated in favor of Streamable HTTP in newer MCP versions (as of March 2025), contrary to older documentation that may have recommended SSE. Below, I'll outline the key differences based on their architecture, usage, and implications.
Overview
- SSE (Server-Sent Events) at /sse: This is the legacy transport for unidirectional, real-time event streaming from server to client over HTTP. It's typically exposed at a GET endpoint like /sse or /events (variations exist across implementations, but /sse matches some older docs). It was designed for simplicity in streaming updates but requires separate endpoints for requests and responses.
- Streamable HTTP at /mcp: This is the modern, recommended transport for bidirectional, stateless communication. It uses a single unified endpoint (/mcp) supporting both POST (for requests and initialization) and optional GET (for upgrading to SSE streams if needed). It's preferred for new integrations due to improved flexibility and reliability.
Key Differences
Here's a structured comparison:
| Aspect | SSE at /sse | Streamable HTTP at /mcp |
|---|---|---|
| Endpoints | Typically requires two: GET /sse (or /events, /connect) for establishing the persistent SSE connection to receive server events; separate POST endpoint (e.g., /messages) for client-to-server requests. | Single unified endpoint (/mcp) for all interactions: POST for sending JSON-RPC messages and initialization; optional GET to upgrade to an SSE stream for ongoing responses. |
| Communication Direction | Primarily unidirectional (server-to-client streaming); client requests are handled via a separate POST but lack built-in bidirectionality without additional setup. | Bidirectional by design, with support for streaming responses and server-initiated messages via optional SSE upgrade. |
| Session Management | Uses query parameters (e.g., sessionId in URL) to track sessions; relies on long-lived, stateful connections that must remain open for streaming. | Uses headers (e.g., mcp-session-id) for session tracking; supports stateless mode (no sessionId needed), making it easier to scale and resume interrupted streams. |
| Resumability & Reliability | No native support for resumable streams; if the connection drops, reconnection is automatic (via browser APIs like EventSource) but may lose data without custom handling. Includes built-in retry logic and last-event-ID tracking. | Built-in resumability using stream IDs as cursors; handles broken connections better by allowing redelivery of lost messages without requiring always-on, long-lived connections. |
| Performance & Overhead | Lightweight for small, frequent updates but adds formatting overhead (e.g., event fields like data, id); can lead to resource exhaustion from persistent connections. | More efficient for large or binary data with no event formatting; lower overhead in high-throughput scenarios, better for bandwidth-constrained environments. |
| Complexity | Simpler client-side (native browser support via EventSource API); but server must manage stateful connections, complicating scalability (e.g., needs sticky sessions or shared state like Redis). | Higher initial complexity (manual parsing and error handling); but simplifies overall architecture with stateless servers and compatibility with standard HTTP tools/proxies. |
| Use Cases | Best for simple real-time notifications, dashboards, or event-driven apps where automatic reconnection is key and bidirectional flow isn't critical. Suitable for older integrations needing compatibility. | Ideal for scalable AI services, public APIs, or high-availability setups; excels in scenarios with large data streams, custom formats, or intermittent connections (e.g., mobile or distributed systems). |
| Pros | - Standardized (HTML5 spec) for consistent behavior.- Easy setup for basic streaming.- Automatic reconnection and error handling. | - Stateless and scalable.- Broad compatibility with HTTP infrastructure.- Flexible data formats and optional streaming. |
| Cons | - Stateful connections hinder load balancing.- Limited to text-based events; no binary support.- Deprecated in MCP for modern use. | - Requires more custom code for reconnection/parsing.- No native browser API (unlike SSE's EventSource). |
| Recommendation | Legacy; use only for backward compatibility with pre-2025 MCP versions. | Recommended for most new integrations due to addressing SSE's limitations like non-resumable streams and stateful requirements. |
Why the Shift in Recommendation?
MCP originally used SSE for its ease in handling streaming AI responses (e.g., partial results during processing). However, it switched to Streamable HTTP to overcome SSE's drawbacks: inability to resume interrupted streams, dependency on highly available long-lived connections, and restrictions on message delivery direction. This makes Streamable HTTP more stable, compatible with serverless setups, and easier to integrate with existing HTTP ecosystems.
If you're working with a specific MCP implementation or version, check the latest docs for exact endpoint details, as variations exist (e.g., some older servers use /connect instead of /sse).