Streamable HTTP is one MCP endpoint: clients POST JSON-RPC, the server replies with plain JSON or upgrades to an SSE stream. It is the current remote transport, replacing HTTP+SSE.
Imagine ordering at a counter with one window. Most orders are quick: you ask, the clerk hands the item straight back. That is a normal HTTP POST returning JSON. But some orders take a while and come in pieces, like a multi-course meal. For those, the clerk keeps the window open and passes you each course as it is ready, which is the optional streaming upgrade. You also get a ticket number, so if you step away you can come back and pick up where your order left off. That ticket is the session id, and resuming is the resumability feature. Old MCP needed two windows, one to listen and one to talk. Streamable HTTP uses just one window for everything.
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.
Transport is the layer beneath everything else in MCP. The primitives, tools, resources, and prompts all travel as JSON-RPC 2.0 messages, but those messages need a pipe to flow through. MCP defines two standard pipes: stdio for local servers and Streamable HTTP for remote ones. Streamable HTTP is the current remote standard, and it explicitly replaced the earlier HTTP plus SSE transport.
The question pairs two things an interviewer cares about. First, the mechanics: what does Streamable HTTP actually do on the wire? Second, the judgment call: given a deployment, do you reach for HTTP or for stdio? Getting both right signals you have shipped a real MCP integration, not just read the headline.
This deep dive walks the wire protocol, the session and resumability model, the history that motivated the redesign, and the decision rule for picking a transport. The throughline is simple: Streamable HTTP makes a remote MCP server behave like an ordinary, scalable web service while still supporting the streaming and server-push that agents need.
The single-endpoint POST model
Streamable HTTP exposes one HTTP endpoint, often something like /mcp. The client sends every JSON-RPC message to that URL with an HTTP POST. There is no second channel and no separate listen URL. This single-endpoint shape is the central design difference from the transport it replaced.
The request body is a JSON-RPC request, response, or notification, exactly the same message format stdio uses. Only the envelope changes, so a server author writes the same handlers regardless of transport. The client also sets an Accept header advertising that it can handle both a JSON reply and an SSE stream, which lets the server choose how to answer on a per-request basis.
The method matters too. Client-to-server traffic is always a POST. A separate GET on the same URL is reserved for opening a server-initiated stream. An optional DELETE on the same URL terminates a session. So one path multiplexes three concerns through standard HTTP verbs rather than inventing a bespoke framing protocol.
Because it is ordinary HTTP, it rides on existing infrastructure: reverse proxies, API gateways, CDNs, TLS terminators, and serverless runtimes all handle a POST without special configuration. There are no custom ports to open and no long-lived socket assumptions to violate. That is precisely why it works in places the older transport could not, and why a server can be deployed the same way any web service is.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Concern | stdio | Streamable HTTP | HTTP+SSE (deprecated) |
|---|---|---|---|
| Location | Local child process | Remote or local over network | Remote over network |
| Endpoints | stdin and stdout pipes | Single HTTP endpoint | Two: SSE channel plus POST |
| Server push | Over stdout stream | Optional SSE upgrade on response | Persistent SSE connection |
| Serverless friendly | Not applicable | Yes, survives cold starts | No, needs sticky connection |
| Session and resume | Process lifetime | Session id header, resumable | Tied to open SSE socket |
Real products, models, and research that use this idea.
- Cloudflare documents deploying remote MCP servers on Workers using Streamable HTTP, which suits stateless serverless runtimes.
- Anthropic's MCP TypeScript SDK ships a StreamableHTTPServerTransport that supersedes the deprecated SSEServerTransport.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy did HTTP+SSE fail on serverless platforms, and how does Streamable HTTP fix it?
The old design assumed one long-lived SSE socket plus a separate POST; serverless functions are short-lived and stateless. Single-endpoint POST with optional streaming and a session header survives cold starts and horizontal routing.
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.
Calling it a WebSocket transport. Streamable HTTP is plain HTTP: a POST whose response is either JSON or an SSE stream, on a single endpoint.
60 second bullets to scan on the way to the call.
The single-endpoint POST model of Streamable HTTP
The two response modes: plain JSON versus SSE stream
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.