MCP Streamable HTTP: Why the Old HTTP+SSE Transport Was Deprecated

The MCP spec quietly changed around March 26, 2025: the old HTTP + SSE transport was marked deprecated, and Streamable HTTP became the default. This rewrites the rhythm of how AI agents interact with tools and context. The old approach was like a clingy night watchman who had to stare at a dedicated line 24/7; the new one is like a well-mannered assistant who shows up when needed and leaves when done.

The Old Model: Two Endpoints, Persistent Pain

In the legacy HTTP + SSE era, the transport was split across two endpoints. Clients had to manage both a POST channel for sending commands and a dedicated SSE channel for receiving messages. The SSE line had to stay online around the clock, and the server had to keep resources on standby. Any network hiccup could drop the connection and lose context, forcing developers to write extra recovery logic while server resources burned continuously.

The connection model was the core problem:

• A dedicated SSE channel had to remain open even when idle
• Servers carried the burden of always-available long-connection pools, limiting scalability
• Load balancers and proxies needed special handling for these "perpetual" connections
• CORS, auth, and modern gateway infrastructure frequently conflicted with the design
• The architecture was awkwardly one-directional, making server-initiated messages difficult

Streamable HTTP: On-Demand Flow in a Single Endpoint

The new protocol consolidates everything into one endpoint. Clients send a POST, and the server either:

1. Returns a normal application/json response for short interactions, or 2. Dynamically upgrades the response to text/event-stream for streaming needs (token-by-token LLM output, long-task progress), using the familiar SSE format within the same request

After finishing, the server SHOULD close the stream — no need to keep it hanging. Standalone GET requests for SSE streams and session management are also supported.

The official docs stress the design does not require long-lived HTTP connections. Servers no longer need to hold resources for pushes that may come at any time, and a stateless variant even lets ephemeral servers participate easily.

Session Resumption

After a disconnect, a client reconnects with its Mcp-Session-Id and Last-Event-ID, and the server resumes pushing events from where it left off instead of restarting the whole stream. This matters enormously for multi-step tool calls and long-context reasoning — imagine losing a half-written report because the network jittered. The new mechanism is like an auto-save checkpoint for conversations.

Long or Short Connections? A Flexible Philosophy

Streamable HTTP isn't a traditional short connection (which closes TCP immediately after request-response), nor is it the forced persistence of the old SSE model. It's "long only when needed": ordinary requests can be short- or medium-lived, and only streaming responses stay open until completion or server-initiated close. A streamable_stateless mode leans even more short-connection friendly.

The result: under high concurrency, resource allocation becomes elastic, deployment complexity drops, and the transport is naturally compatible with existing proxies, load balancers, and auth infrastructure. CORS stops being an obstacle; stateless architecture makes cloud-native scaling easier.

Why MCP Made the Switch

The old transport's pain points were real: unrecoverable connections, mandatory high-availability long connections, one-way push only, and friction with modern web infrastructure. Once agent workloads scaled, these became genuine bottlenecks — developers often spent more effort on connection management and recovery logic than on business logic.

Streamable HTTP solves multiple pains at once: it keeps streaming capability, adds bidirectional support (server can send requests/notifications within the same stream before the response), session management, and resumability.

Recommendation

• New projects and MCP servers: go straight to Streamable HTTP. Half the endpoints, on-demand connections, better scaling, deployment-friendly.
• Legacy systems: no panic — backward compatibility is retained, so you can run both endpoints in parallel and migrate gradually.
• One caveat: if you're not talking about MCP but general web development SSE vs HTTP chunked streaming, the conclusion differs slightly — both are long-lived; the difference lies mainly in format standardization and convenience (SSE has the fixed data:/event: format, EventSource API, and auto-reconnect). But in the MCP context, the shift is clear.

This transport transition looks like a minor protocol tweak, but it marks AI agent infrastructure maturing. The old dream is over; the new road is lighter. Developers can finally put more energy into what matters: making conversations between models, tools, and context more natural and reliable.

References

1. MCP official spec update (deprecation of legacy HTTP + SSE in favor of Streamable HTTP, March 26, 2025) 2. MCP transport comparison: how single-endpoint Streamable HTTP works 3. MCP session resumption and Last-Event-ID resumability explained 4. From persistent long connections to on-demand streaming: MCP architecture evolution and migration guide 5. Best practices for agent toolchain MCP integration — Streamable HTTP advantages under high concurrency