**Streamable HTTP** is how a remote MCP server and its host talk over the network. The whole thing lives behind one URL. The client sends a JSON-RPC message with an HTTP POST, and the server answers.
The clever part is the response. For a quick reply, the server just returns a normal JSON body and the request ends. For a slow tool, or when the server needs to push notifications, it upgrades the same response into a stream using Server-Sent Events. So one endpoint covers both fast and slow cases.
Each conversation gets a session id, sent in a header. That lets the server keep per-session state and lets the client reconnect after a dropped connection without starting over.
You choose Streamable HTTP whenever the server is remote: a cloud VM, a serverless function, or a managed service. You use stdio instead when the server runs as a local child process on the same machine as the host, since stdio needs no network at all.
Streamable HTTP is the current remote transport for MCP. It replaced the older HTTP plus SSE design.
Everything runs through a single HTTP endpoint. The client sends each JSON-RPC message as an HTTP POST. The server inspects the request and picks one of two response modes. For a short result it returns a normal JSON body and closes the request. For a long-running call, or to deliver server-initiated notifications, it sets the response to an SSE stream and emits events over that open body.
Sessions are tracked with a header. On initialize, the server may return an `Mcp-Session-Id`, and the client echoes it on every later request. Because streamed events carry IDs, a client that drops can reconnect and resume from the last event it saw, so it never misses messages.
Choose Streamable HTTP whenever the server is remote or deployed: a cloud host, a Cloudflare Worker, or any managed service reachable over the network. It works on ordinary HTTP infrastructure, including serverless. Reach for stdio only when the server is a local child process on the same machine, where a network hop would add pure overhead.
Quick reference
TL;DR
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.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
A purely local tool running as a child process of the host on the same machine stdio needs no ports, auth, or network hop, so HTTP only adds latency and operational overhead.
A prototype where you control both ends and want the fastest path to a working tool stdio launches with a single config line and avoids deployment, TLS, and session plumbing entirely.
Environments that forbid outbound network calls from the host process A remote HTTP transport cannot reach a blocked network, so a local stdio server is the only viable option.
Quick scan · 2–4 min
Everything important, quickly.
4 min: single-endpoint POST model, plain JSON vs SSE-upgrade responses, the session id header, resumability via event IDs, why it replaced HTTP+SSE, and when stdio still wins.
Side-by-side
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-world examples
Real products, models, and research that use this idea.
1Cloudflare documents deploying remote MCP servers on Workers using Streamable HTTP, which suits stateless serverless runtimes.
2Anthropic's MCP TypeScript SDK ships a StreamableHTTPServerTransport that supersedes the deprecated SSEServerTransport.
3Claude Code and Claude Desktop connect to remote MCP servers over Streamable HTTP while still spawning local servers over stdio.
Interviewer follow-ups
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?
Sign in or go Pro to see the approach for this follow-up.
QHow does a stateless worker fleet keep a coherent MCP session across many requests?
Sign in or go Pro to see the approach for this follow-up.
QHow exactly does resumability work when a streamed response drops mid-flight?
Sign in or go Pro to see the approach for this follow-up.
QWhat authentication model does Streamable HTTP enable that stdio does not need?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
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.