Compare stdio, HTTP+SSE, and Streamable HTTP as MCP transports. For each, describe the mechanism, its status, and the deployment scenario where it belongs.
Free · 2 AI evals / day
MCP carries the same JSON-RPC messages over different pipes, and the pipe you pick depends on where the server runs.
**stdio** is for local servers. The host launches the server as a subprocess and talks to it through that process's stdin and stdout. Messages are JSON-RPC, one per line. There is no network and no port, so nothing outside the machine can reach it. This is the default for developer tools like a filesystem or Git server.
Streamable HTTP is for remote servers. The server lives on a separate machine, a cloud VM, or a serverless function, and the host reaches it over a single HTTP endpoint. It can stream long results back. This is the current standard whenever the server is not on the same box as the host.
HTTP+SSE was the older remote transport. It split traffic across two channels: Server-Sent Events for server to client and plain HTTP POST for client to server. That split was awkward to manage, so it was deprecated in 2025. Avoid it in new code.
The rule of thumb: local means stdio, remote means Streamable HTTP, and HTTP+SSE is legacy.
MCP defines one message format, JSON-RPC 2.0, and several transports that carry it.
**stdio** runs the server as a local subprocess. The host writes JSON-RPC to the process's stdin and reads replies from its stdout. There is no socket and no network surface. It is fast, host-privileged, and current. Use it for tools on the same machine as the host.
The remote story changed in 2025. The original remote transport was HTTP+SSE. It used a Server-Sent Events stream for server to client traffic and a separate HTTP POST channel for client to server. Two channels for two directions meant an asymmetric connection lifecycle. Reconnection and session resumption were hard to get right. It was deprecated mid-2025.
The replacement is Streamable HTTP. Everything flows through a single HTTP endpoint. The client POSTs requests, and the server replies either with a plain JSON body or an SSE stream on that same response. One endpoint supports sessions, resumability, and OAuth for auth. Use it for any remote server: a cloud VM, a serverless function, or a shared endpoint.
Choose by deployment. Local subprocess picks stdio. Remote picks Streamable HTTP. HTTP+SSE is legacy, so never reach for it in new work.
Quick reference
TL;DR
stdio runs a local subprocess over stdin/stdout; Streamable HTTP is the current remote transport over a single endpoint; HTTP+SSE was its two-channel predecessor, now deprecated.
Think of plugging in a new gadget. stdio is like a USB cable straight into your own laptop: the tool lives on the same machine, talks through the program's own input and output pipes, and nobody on the internet can reach it. Streamable HTTP is like calling a service over the web: the tool runs on some cloud server far away, and you reach it through one web address that can also stream long answers back to you. HTTP+SSE was an older way of doing that web call. It used two separate pipes, one to send and one to listen, and keeping both in sync turned out to be fiddly. So the MCP designers replaced it with the simpler single-pipe version. Pick the local cable for local tools and the web call for remote ones.
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.
Server must be reachable by hosts on other machines or in the cloud stdio has no network surface; only Streamable HTTP can serve a remote connection.
Starting a brand-new remote MCP server in 2026 HTTP+SSE is deprecated and its two channel lifecycle is fragile; use Streamable HTTP instead.
A tightly co-located tool with a sub-millisecond latency budget An HTTP transport adds network and serialization overhead that a local stdio subprocess hop avoids.
Quick scan · 2–4 min
Everything important, quickly.
5 min: name all three transports, give the mechanism of each, explain the HTTP+SSE deprecation, then state the local vs remote decision rule with the scaling and auth implications.
Side-by-side
Aspect
stdio
HTTP+SSE (deprecated)
Streamable HTTP
Mechanism
Subprocess stdin and stdout
SSE stream plus separate POST
Single HTTP endpoint, optional SSE
Reach
Local only, no network
Remote
Remote
Channels
One duplex pipe pair
Two asymmetric channels
One endpoint, both directions
Status
Current
Deprecated mid-2025
Current standard for remote
Auth and sessions
Inherits host privileges
Awkward, fragile lifecycle
OAuth 2.1 plus session header
Use when
Server co-located with host
Never in new code
Server is remote or scaled
Real-world examples
Real products, models, and research that use this idea.
1Claude Code and Claude Desktop launch local filesystem and Git servers over stdio as subprocesses defined in the config file.
2Remote MCP servers for GitHub and Linear in 2026 ship over Streamable HTTP with OAuth, so any compliant host can connect over the network.
3Hosted MCP gateways deployed on serverless platforms use Streamable HTTP behind a load balancer, resuming sessions via the session-id header.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does Streamable HTTP keep session state across a load-balanced, stateless server tier?
Sign in or go Pro to see the approach for this follow-up.
QWhy is a host-privileged stdio server a security concern, and how do you contain it?
Sign in or go Pro to see the approach for this follow-up.
QWhen does Streamable HTTP actually open an SSE stream rather than return a plain JSON body?
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
Trying to point a host at a stdio server running on another machine. stdio has no network surface; remote servers need Streamable HTTP.