Zenaique

Compare the three MCP transports and identify the correct choice for each deployment scenario

Short answer·Medium·4.0 · 0·~3 min·Asked atPhonepeReliance JioSynthesia·Relevant atAnthropic
Attempt it

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
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.

Memory aid
Sign in to see the mnemonic that makes this stick.
Easy to grasp

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.

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 blur: 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 is the single most important framing for the question, because it tells you immediately that the transport choice never touches your tool handlers; it only touches how the host and server are wired together.

This question is really about matching a pipe to a deployment. There are three transports in the conversation: stdio, the deprecated HTTP+SSE, and the current Streamable HTTP. Two of them are alive and one is legacy. Knowing which is which, and why the legacy one fell out, is exactly the kind of thing an interviewer probes to see whether you have actually shipped an MCP integration or only read the headline. The HTTP+SSE deprecation in particular is a recent enough event that knowing the date and the reason signals hands-on familiarity rather than a stale mental model.

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 in 2026 that means Streamable HTTP. The rest is detail about lifecycle, security, and scaling, and each of those axes reinforces 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, and the host process is then responsible for spawning and reaping it.

The defining property is that there is no network. No socket is opened, no port is bound, 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 is also why a malicious local server is dangerous: it runs with whatever the host can do, which is why hosts gate sensitive tool calls behind explicit user approval. stdio is current and not deprecated; it is simply scoped to the local case, and treating it as obsolete is a common and revealing mistake.

HTTP+SSE: the deprecated remote transport
Streamable HTTP: the current remote standard
Choosing a transport: the decision rule
Security and lifecycle implications
Sign in to unlock the full deep dive.

Situations where this technique stops working.

Sign in to see when this approach fails.

2–4 min · Everything important, quickly.

Sign in to see the quick scan of the deep dive.
AspectstdioHTTP+SSE (deprecated)Streamable HTTP
MechanismSubprocess stdin and stdoutSSE stream plus separate POSTSingle HTTP endpoint, optional SSE
ReachLocal only, no networkRemoteRemote
ChannelsOne duplex pipe pairTwo asymmetric channelsOne endpoint, both directions
StatusCurrentDeprecated mid-2025Current standard for remote
Auth and sessionsInherits host privilegesAwkward, fragile lifecycleOAuth 2.1 plus session header
Use whenServer co-located with hostNever in new codeServer 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 in 2026 ship over Streamable HTTP with OAuth, so any compliant host can connect over the network.
Sign in to see more production examples.

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?
A

The server issues an Mcp-Session-Id on initialize; the client echoes it on every request, so any node can rehydrate or route the session without a sticky connection.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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.

Sign in to see all red flags and common mistakes.

60 second bullets to scan on the way to the call.

  • The mechanism behind stdio transport

  • Why stdio cannot serve a remote machine

Sign in to unlock the revision sheet.

Primary sources. Browse if you want the original framing.

Similar questions

Same topic, related formats. Practice these next.

4 curated
Next question
What is the Model Context Protocol (MCP) and what problem does it solve?
MCQ·Easy