Compare the three MCP transports and identify the correct choice for each deployment scenario
Compare stdio, HTTP+SSE, and Streamable HTTP as MCP transports. For each, describe the mechanism, its status, and the deployment scenario where it belongs.
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 and talks through the program's own input and output pipes. 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. 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 was hard. 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.
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.
MCP separates two things that beginners often confuse: the message format and the transport. The message format is fixed. Every MCP exchange is JSON-RPC 2.0, the same request, response, and notification shapes regardless of how the bytes travel. The transport is the pipe those bytes move through, and MCP defines more than one. This separation means the transport choice never affects your tool handlers; it only affects how the host and server connect.
Choosing a transport means matching a pipe to a deployment. There are three transports to know: stdio, the deprecated HTTP+SSE, and the current Streamable HTTP. Two of them are current and one is legacy.
The organizing principle is simple. Ask where the server runs relative to the host. If it is the same machine, you want a local subprocess pipe. If it is across a network, you want an HTTP transport, and that means Streamable HTTP. The rest is detail about lifecycle, security, and scaling. Each of those axes supports the same local versus remote split rather than complicating it.
stdio: the local subprocess transport
With stdio the host launches the MCP server as a child process and talks to it through that process's standard input and standard output. The host writes a JSON-RPC request to the server's stdin; the server writes its reply to stdout. Messages are newline-delimited, one JSON object per line, and stderr is left free for the server's own logging. The host typically declares the server in a config file by giving the command, its arguments, and any environment variables. The host process then spawns and reaps it.
The defining property is that there is no network. Nothing opens a socket or binds a port, and nothing outside the machine can address the server. That makes stdio the natural fit for local developer tooling: a filesystem server, a Git server, or a database client running on the same laptop as the host. It also means the server's lifecycle is bound to the host. When the host exits, the child exits, so there are no orphaned long-running daemons to manage and no listening surface left behind.
Two further consequences follow. First, latency is just a process hop with no network round-trip, so stdio is the fastest transport and the right pick when per-call overhead matters. Second, the subprocess inherits the host's user, environment, and filesystem access. That host-privileged model is convenient, but it is also why a malicious local server is dangerous. It runs with whatever the host can do. That is why hosts gate sensitive tool calls behind explicit user approval. stdio is current and not deprecated; it is scoped to the local case. Treating it as obsolete is a common and revealing mistake.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| 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 March 2025 | Current standard for remote |
| Auth and sessions | Inherits host privileges | Awkward, fragile lifecycle | OAuth 2.1 when required, no protocol sessions |
| Use when | Server co-located with host | Never in new code | Server is remote or scaled |
Real products, models, and research that use this idea.
- Claude Code and Claude Desktop launch local filesystem and Git servers over stdio as subprocesses defined in the config file.
- Remote MCP servers for GitHub and Linear ship over Streamable HTTP with OAuth, so any compliant host can connect over the network.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does a Streamable HTTP server keep cross-call state across a load-balanced, stateless server tier?
The current transport has no protocol sessions: every POST is self-contained, so any node can serve it without a sticky connection. A server that needs cross-call state creates an explicit handle, returns it in a tool result, and receives it back as a tool argument. It keeps the state in a shared store.
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.
Trying to point a host at a stdio server running on another machine. stdio has no network surface; remote servers need Streamable HTTP.
60 second bullets to scan on the way to the call.
The mechanism behind stdio transport
Why stdio cannot serve a remote machine
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.