Match each MCP transport to its defining characteristic and correct deployment scenario
Drag each answer to line up with its matching prompt
stdio
Local child process, newline delimited JSON over stdin/stdout, no network exposure: for local developer tools
HTTP+SSE (deprecated)
HTTP POST for all messages with optional chunked streaming: current standard for remote/cloud deployed servers
Streamable HTTP
Asymmetric transport: SSE for server→client, POST for client→server. Deprecated mid-2025 due to connection lifecycle issues
stdio is a local subprocess over stdin/stdout; HTTP+SSE was the deprecated two-channel remote transport; Streamable HTTP is the current single-endpoint remote standard.
Think of three ways to talk to a helper. stdio is like passing handwritten notes to a coworker at your desk: instant, private, no phone needed. HTTP+SSE was an old long-distance setup with two separate phone lines, one to listen and one to speak, which kept dropping calls when the listen line broke. Streamable HTTP is the modern long-distance line: one number you call for everything, and it can keep streaming back to you when there is a lot to say. All three carry the same messages. They just differ in whether the helper sits beside you or lives across the network, and how reliably the line stays up.
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 is two things stacked together, and this question is really testing whether you keep them separate. The upper thing is the protocol: every MCP message is a JSON-RPC 2.0 request, response, or notification. The lower thing is the transport: the actual pipe those bytes travel through. A transport never changes the message shape. It only changes where the server lives, how the connection stays open, and what reliability and security you inherit.
The match pairs three transports against three characteristics, and the trap is treating them as three competing message formats. They are not. They are three deployment topologies for the same JSON-RPC traffic. Once you anchor on a single axis, local versus remote, and then split remote into the deprecated design versus the current one, the matching falls out cleanly.
This deep dive defines each transport, explains exactly why HTTP+SSE was retired, shows what Streamable HTTP changed, and gives you the one-axis mental model that makes the match obvious in an interview.
Transport versus protocol: the distinction the question hinges on
Start by separating the two layers, because every wrong answer here collapses them.
The protocol is JSON-RPC 2.0. A client sends a request with a method name like tools/list and an id; the server returns a response with that id; either side can send notifications with no id. This is identical no matter how the bytes move. The transport is the delivery mechanism underneath: a local pipe, or an HTTP connection across a network. The connection also begins the same way regardless of transport, with an initialize handshake where the two sides negotiate capabilities and protocol version.
The reason this matters in the match is that the three left-hand items are transports, and each right-hand item describes a delivery mechanism plus a deployment scenario, never a different message schema. If you find yourself thinking one transport speaks a different language than another, you have conflated the layers. They all carry the same JSON-RPC envelopes. What differs is locality, connection lifecycle, and the reliability you get for free.
A useful sanity check during the match: read each right-hand clue and ask whether it is describing a wire mechanism (pipes, sockets, streams) or a message format. Every one of them describes a mechanism. None of them mentions a different request or response shape, because there is only one shape. That observation alone tells you the three options differ on deployment, not on language, which is the framing the rest of the answer builds on.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Transport | Channels | Network | Status / use |
|---|---|---|---|
| stdio | stdin/stdout, newline-delimited JSON | None, local subprocess | Current, local developer tools |
| HTTP+SSE | SSE server to client + POST client to server | Remote | Deprecated mid-2025 |
| Streamable HTTP | Single endpoint, POST + optional chunked stream | Remote | Current standard for remote servers |
Real products, models, and research that use this idea.
- Claude Desktop and Claude Code launch local filesystem and Git servers over stdio as child processes configured in a JSON config file.
- Anthropic's 2025 MCP spec revision deprecated HTTP+SSE and made Streamable HTTP the recommended transport for remote servers.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy did the asymmetric two-channel design of HTTP+SSE cause connection lifecycle problems?
Trace what happens when the long-lived SSE stream drops mid-session: reconnection and message ordering, plus how stateless load balancers handle a persistent stream versus discrete POSTs.
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 HTTP+SSE the current remote transport. It was deprecated in 2025 and replaced by Streamable HTTP, which uses one endpoint for both directions.
60 second bullets to scan on the way to the call.
Which transport runs the server as a local subprocess
How stdio frames its JSON messages over standard streams
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.