I recently went through the MCP specification again. Around March 26, 2025, the official spec quietly marked the old HTTP + SSE transport as deprecated, promoting Streamable HTTP as the default. The change may seem minor, but it directly reshapes the rhythm of how AI agents interact with tools and context. The old approach was like a clingy night watchman who had to keep eyes on a dedicated line 24/7; the new one is like a well-mannered assistant who shows up when needed and leaves when done. The difference is obvious — and it carries far-reaching implications for the whole ecosystem.
🌐 The Old Dream of MCP Transport: The Hidden Pain of a Two-Endpoint War
In the old HTTP + SSE era, the endpoint was split in two. Clients had to manage both a POST channel for sending commands and a dedicated SSE line for receiving messages. Two channels running in parallel, like two faucets that can never be turned off. The SSE line in particular had to stay online at all times, and the server had to be perpetually on standby. Any network hiccup could sever the connection and wipe out context. Developers had to write extra recovery logic while server resources kept burning. The design barely worked when streaming needs first emerged, but once agents scaled up in concurrency, the problems were fully exposed.
The connection model was also painful. The old scheme required a dedicated SSE channel to stay online around the clock, even if nobody called at midnight. Servers carried a heavy burden, keeping highly available long-connection pools on standby. Scalability was naturally limited — adding machines meant load balancers and proxies needed special accommodation for this "perpetual motion machine." Compatibility was worse: CORS, auth, and modern gateway infrastructure frequently clashed with it. The architecture was awkward, primarily one-way push, making it hard for servers to proactively say anything.
⚡ The Magic of Streamable HTTP: On-Demand Flow in a Single Endpoint
The new protocol turned the page. Clients POST to a single unified endpoint. On receipt, the server either returns a plain application/json response for short interactions, or dynamically upgrades the same response to text/event-stream when streaming is needed — say, LLM tokens emitted one by one, or long-task progress updates. It's still SSE format, but all within one request, one endpoint. Once done, the server SHOULD close the stream — no need to keep it hanging. Standalone GET requests for separate SSE streams and session management are also supported.
The elegance lies in "on-demand." Ordinary requests follow a normal lifecycle; connections open only when streaming is needed and close when finished. The official documentation repeatedly emphasizes: *does not require long-lived HTTP connection*. Servers can finally breathe — no longer holding resources in reserve for "possible pushes at any time." Stateless variants even let ephemeral servers participate easily. Clients are relieved too: one endpoint to manage, no coordinating two connections.
> A practical session-resume design: after a disconnect, the client re-issues the request with Mcp-Session-Id and Last-Event-ID, and the server resumes pushing from the last event instead of restarting the entire stream. This is critical for multi-step tool calls and long-context reasoning in agents. Imagine a report half-written when a network blip wipes everything — how awful that experience would be. The new mechanism is like an autosave checkpoint for conversations: resumption is natural and smooth, context intact.
🔄 Long-Lived or Short-Lived? Streamable's Flexible Philosophy
Streamable HTTP is not a traditional short connection — traditional short connections close TCP immediately after request-response. But it's also far from the old SSE's forced persistent long connection. Streamable is "long only when needed": ordinary requests can be short- or medium-lived, and streaming responses stay open only until completion or server-initiated close. A streamable_stateless mode is also supported, closer to short-connection friendliness. Server burden drops dramatically. Under high concurrency, resource allocation is more elastic — no more exhausting the connection pool just because "everything must stay online."
That's the key. Under the old model, the server was a night watchman who never rested, resources permanently occupied; the new model turns it into an on-call courier who delivers and departs. Deployment complexity falls sharply, and it's naturally compatible with existing proxies, load balancers, and auth infrastructure. CORS is no longer a roadblock, and stateless architecture makes cloud-native scaling easier.
💥 Old Pain, New Cure: Why MCP Made the Hard Pivot
The old HTTP + SSE pain points were real: unrecoverable connections that lose context on disconnect; servers forced to maintain highly available long connections with poor scalability; one-way-only push with an awkward architecture; heavy conflicts with modern web infrastructure. Once agents scaled, these became genuine bottlenecks. Energy spent on connection management and recovery logic often exceeded the business logic itself.
Streamable HTTP solves multiple pains in one stroke. It keeps streaming capability and adds bidirectional support (the server can send requests/notifications within the same stream before the response), session management, and resumability. The architecture is cleaner, deployment simpler, compatibility better. Servers are no longer held hostage by persistent connections, and client code is simpler. Stability under high concurrency in production is noticeably improved.
🚀 The Verdict: Streamable for New Projects, Smooth Transition for Legacy
For new projects and new MCP servers, go straight to Streamable HTTP — don't touch the old SSE. The benefits are clear: half the endpoints, on-demand connections, strong scalability, deployment-friendly. Legacy systems needn't panic: the official spec retains backward compatibility, so you can run both endpoints in parallel and migrate gradually. Especially for Agent/LLM toolchain builders — as demonstrated by practices like the KLIP series — the new approach clearly wins on high concurrency, production deployment, and connection stability, and deserves priority adoption.
One caveat: if we're not talking about MCP but SSE vs HTTP chunked streaming in general web development, the conclusion differs somewhat: both are long-lived connections, and the main differences are format standardization and convenience (SSE has a fixed data:/event: format, the EventSource API, and auto-reconnect). But in terms of precise terminology, 99% of the time this discussion points to the MCP context.
This transport shift may look like a minor protocol patch, but it marks the maturing of AI agent infrastructure. After reading through the spec, my one takeaway: the old dream is over, and the new road is lighter. Developers can finally put more energy back where it belongs — making the conversation between models, tools, and context more natural and more reliable.
-----
References
1. MCP official specification update notes (deprecation of old HTTP + SSE and shift to Streamable HTTP as default, March 26, 2025) 2. Model Context Protocol 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 integration with MCP — validation of Streamable HTTP's advantages under high concurrency