What is SSE Transport?
Updated on
SSE Transport in MCP usually means the legacy HTTP+SSE transport that opened a persistent GET event stream and sent client messages to a separate POST endpoint; it is deprecated and new implementations should use Streamable HTTP.
Quick Facts
| Specification | Official Specification |
|---|
How It Works
Legacy HTTP+SSE contract
A legacy Client opened a GET connection to the Server's SSE endpoint. The Server sent an endpoint event that identified where the Client should POST JSON-RPC messages, and later delivered Server messages on the event stream. This split GET-plus-POST design belongs to the 2024-11-05 protocol revision. Documentation, logs, and configuration should call it legacy HTTP+SSE, not just SSE, to prevent version ambiguity.
Current Streamable HTTP
Streamable HTTP replaced legacy HTTP+SSE. Under the 2026-07-28 revision, the Server exposes one MCP endpoint that accepts POST, and every JSON-RPC request travels in its own POST. The Server returns either one JSON object or an SSE stream scoped to that request. There is no protocol handshake, Mcp-Session-Id, or general GET event endpoint in this revision.
Where SSE still appears
SSE remains a response encoding inside current Streamable HTTP, not the name of the transport. A request-scoped SSE response may carry related progress or log notifications before its final JSON-RPC response. Long-lived change notifications use the SSE response to a subscriptions/listen POST. Closing a request response stream cancels that request, and resumable streams through Last-Event-ID are not supported.
Migration and compatibility
New implementations should not adopt legacy HTTP+SSE. A Server that still supports old Clients can keep legacy GET and POST routes beside the current MCP POST endpoint, while a Client can probe the current endpoint and fall back only when required. Track the negotiated protocol revision in tests and telemetry. Do not infer a session, replay policy, or endpoint shape from the presence of text/event-stream alone.
Security and operations
Remote transports require TLS, authentication, object-level authorization, request limits, tenant isolation, and secret-safe logs. Current Streamable HTTP Servers must validate Origin; local Servers should bind to loopback. For SSE responses, disable proxy buffering when needed, use bounded keep-alives for long-lived subscriptions, propagate cancellation, cap concurrent streams, and test proxy, timeout, backpressure, and rolling-deployment behavior.
Key Characteristics
- Legacy identity: HTTP+SSE refers to the separate GET stream and POST message endpoints from MCP 2024-11-05
- Deprecated status: new implementations should use Streamable HTTP and existing deployments should plan migration
- Current distinction: SSE may encode a Streamable HTTP response without making the transport legacy HTTP+SSE
- Versioned behavior: endpoint, session, cancellation, and notification rules depend on the negotiated MCP revision
- Compatibility burden: dual-stack Servers need explicit routing, telemetry, tests, and a retirement plan
- Remote-system controls: Origin validation, authentication, authorization, buffering, limits, and observability remain mandatory
Common Use Cases
- Identifying whether an older MCP Client or Server still expects GET `/sse` plus a POST message endpoint
- Planning a measured migration from legacy HTTP+SSE to the current Streamable HTTP endpoint
- Maintaining temporary backward compatibility while collecting protocol-version telemetry
- Debugging proxies that buffer or terminate request-scoped SSE responses and subscription streams
- Reviewing remote MCP security controls before legacy routes are exposed during migration
Example
Loading code...Frequently Asked Questions
Is SSE Transport still the recommended MCP remote transport?
No. The legacy HTTP+SSE transport from MCP 2024-11-05 is deprecated. New implementations should use Streamable HTTP. Existing systems can retain legacy routes temporarily for compatible Clients, but should measure their use and publish a migration and retirement plan.
Does current Streamable HTTP still use SSE?
It can. A POST request may receive either an `application/json` response or a request-scoped `text/event-stream` response. A `subscriptions/listen` POST can also produce a long-lived notification stream. This use of SSE does not restore the deprecated separate GET `/sse` transport.
What changed in Streamable HTTP revision 2026-07-28?
The revision removed the general GET stream endpoint and protocol-level sessions. Each JSON-RPC request is sent in its own POST with protocol and routing metadata, and the response is JSON or an SSE stream scoped to that request. Server-to-client interactions use the revision's multi-round-trip mechanism.
How should a Server support old and new MCP Clients?
Expose the current MCP POST endpoint and, only while needed, keep the legacy GET and message POST routes. Use protocol-aware negotiation or probing, test both paths, log which revision is used, prevent route collisions, and remove legacy support after clients have migrated.
What production failures should SSE paths be tested for?
Test proxy buffering, idle timeouts, cancellation, slow consumers, concurrent-stream limits, keep-alive behavior, partial writes, rolling deployment, authentication expiry, and duplicate retries. Record request IDs and protocol revisions without logging sensitive payloads.