HTTP+SSE split the two directions across a long-lived SSE stream and separate POSTs; that asymmetry broke on serverless and stateless infra, so Streamable HTTP replaced it with one endpoint.
Imagine ordering at a drive-through where you shout your order through one window but the food comes out a totally different window that has to stay open the whole time. If that second window ever closes, the kitchen loses track of your whole order. The old MCP remote transport worked like that: replies streamed back on a long-open server channel while your requests went through a separate door. Cloud platforms that spin servers up and down hated keeping that channel open. The new design uses a single window for both ordering and receiving. The reply can still stream when needed, but nothing has to stay propped open, so it works on platforms that start fresh for every request.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
This question rewards candidates who understand that MCP separates its message layer from its transport layer. The JSON-RPC 2.0 messages that flow between a host and a server are identical no matter how they travel. The deprecation in 2025 touched only the remote transport, not the protocol semantics. Getting that distinction right is half the answer.
The wrong answers in the question are all plausible-sounding distractors. SSE never depended on WebSockets. The transport carried text JSON-RPC, not binary tool payloads. And nothing in MCP forced a server-side database. The real story is about an asymmetric two-channel design that made connection lifecycle management painful and clashed badly with modern stateless hosting.
This deep dive walks through what the old HTTP+SSE transport actually did, why its shape caused trouble, how Streamable HTTP fixed it, and how to talk about the tradeoffs at a senior level.
What the HTTP+SSE transport actually did
MCP shipped in November 2024 with two transports. The stdio transport, for local servers launched as a subprocess, and an HTTP-based transport for remote servers. That remote transport is the one that got deprecated.
Its design was asymmetric. To receive messages from the server, the client opened a long-lived Server-Sent Events stream with an HTTP GET to a dedicated endpoint. SSE is a browser-friendly, one-way push mechanism: the server holds the connection open and writes text/event-stream events down it as they occur. To send messages to the server, the client could not reuse that stream, because SSE is one-directional by design. It issued separate HTTP POST requests to a different endpoint.
The handshake made the coupling concrete. When the client first connected, the server's SSE stream emitted an endpoint event telling the client which URL to POST its requests to. From then on the client correlated the two channels itself: outbound JSON-RPC requests went to the POST URL, and the matching responses and any server-initiated notifications came back down the original SSE stream.
So a single logical session ran over two physically distinct channels. One long-open GET stream carrying server to client traffic, and a series of short POSTs carrying client to server traffic. The server had to correlate them so replies landed on the right SSE stream, which is exactly where the trouble started.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Aspect | HTTP+SSE (deprecated) | Streamable HTTP (current) |
|---|---|---|
| Endpoints | Separate SSE stream + POST endpoint | Single unified endpoint |
| Server-to-client | Long-lived SSE GET stream | Optional SSE on the POST response |
| Connection model | Persistent open socket required | Per-request, no held socket |
| Statefulness | Stateful, sticky routing needed | Stateless-friendly |
| Serverless fit | Poor, cannot hold stream open | Clean, maps to Workers and Lambda |
| Spec revision | 2024-11-05 | 2025-03-26 onward |
Real products, models, and research that use this idea.
- Cloudflare's remote MCP server guides target Streamable HTTP so Workers can serve MCP statelessly without holding an SSE socket open.
- Anthropic's MCP spec revision 2025-03-26 introduced Streamable HTTP and deprecated the standalone HTTP+SSE transport from the 2024-11-05 revision.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does Streamable HTTP let a stateless server still support multi-message sessions?
The server issues an Mcp-Session-Id header on initialize; the client echoes it on later requests. State lives in an external store, not in a held socket.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Guessing the answer is about WebSockets or binary payloads. The real reason is the asymmetric two-channel design that broke connection lifecycle on stateless and serverless infra.
60 second bullets to scan on the way to the call.
Why HTTP+SSE used two separate channels for the two directions
What connection lifecycle problems the long-lived SSE stream caused
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.