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 SSE streaming of the response: current standard for remote/cloud deployed servers
Streamable HTTP
Asymmetric transport: SSE for server→client, POST for client→server. Deprecated in March 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. The upper layer is the protocol: every MCP message is a JSON-RPC 2.0 request, response, or notification. The lower layer is the transport: the 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. They are not three competing message formats. They are three deployment topologies for the same JSON-RPC traffic. Focus on a single axis, local versus remote, and then split remote into the deprecated design and the current one. The matching then becomes clear.
Transport versus protocol
Start by separating the two layers.
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. Version and capability negotiation also works the same way regardless of transport: every request carries its protocol version and client capabilities in _meta.
This matters in the match because the three left-hand items are transports. 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.
Here is a useful sanity check during the match. Read each right-hand clue and ask whether it describes 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.
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 March 2025 |
| Streamable HTTP | Single endpoint, POST + optional SSE 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.
- The MCP spec's 2025-03-26 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.