Every MCP server has to answer one question before it writes a single line of tool logic: how does a client actually reach it? A server that runs on your own laptop and a server run by a vendor for thousands of customers are solving the same protocol, but they live under opposite constraints — one has no network to worry about at all, the other has nothing but network to worry about. MCP resolves this with two transports, not one: stdio and Streamable HTTP.
stdio launches the server as a local subprocess and speaks to it over standard input and output — the same pipes a shell script uses to talk to any other command-line program. Streamable HTTP reaches the server as a networked service at a URL, the same way a browser reaches a web API. Both carry the identical MCP message format underneath — same tool definitions, same request/response shapes — the transport only changes how the bytes get from client to server.
In Python's FastMCP, this is a one-line choice: `mcp.run()` defaults to stdio, while `mcp.run(transport="streamable_http", port=8000)` switches to Streamable HTTP. The TypeScript SDK makes the same split explicit as two classes — `StdioServerTransport` from `@modelcontextprotocol/sdk/server/stdio.js` and `StreamableHTTPServerTransport` from `@modelcontextprotocol/sdk/server/streamableHttp.js`. Picking wrong doesn't break the protocol, but it does mean fighting your deployment shape for the life of the server.
Analogy🏏Cricket
🏏 Think of it like cricket: A domestic Ranji Trophy player and Jasprit Bumrah are both bowlers under the same laws of cricket, but nobody expects them to train the same way. The Ranji player nets at his home ground in Baroda, using whatever surface and equipment the local association owns — nobody outside that ground needs to reach him, and his routine answers to his own state team alone. Bumrah trains inside the BCCI's centralized system: NCA-monitored workload, a support staff shared across every format, and a schedule that has to serve the whole national side at once, not just one player. Both are still bowling — same run-up, same wrist position at release, same laws of the game — but the surrounding setup is built for opposite constraints: one person training in a fixed, local, low-overhead way, versus a shared resource that many teams and formats have to draw on reliably. A board that forced every bowler through full NCA infrastructure would waste a Ranji player's time. A board that let Bumrah train like a club cricketer would burn out its biggest asset under national workload. The insight: MCP has the same split. A tool running as your own local process needs a lightweight, answerable-to-one-caller setup — that's stdio. A tool serving many callers as a shared service needs the networked, monitored setup built for shared load — that's Streamable HTTP. Same protocol underneath, two transports for two genuinely different situations.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.