Transport Choice: stdio vs. Streamable HTTP

When to use the stdio transport versus Streamable HTTP for an MCP server, based on trust boundary and deployment shape.

Tools & MCP·Lesson 5 of 6·7 min

MCP defines the message format (JSON-RPC-based) separately from how those messages physically travel between client and server. That physical layer is the transport, and MCP supports two primary transports: stdio and Streamable HTTP. Choosing between them is a deployment decision, not a protocol-capability decision — both transports carry the same primitives (Tools, Resources, Prompts) equally well.

stdio: local, trusted subprocess

With the stdio transport, the host launches the MCP server as a local subprocess and communicates with it over that process's standard input and standard output streams. There is no network involved. This is the natural choice when the server runs on the same machine as the host, is trusted (often because you or your organization wrote it, or it's a well-known open-source server you installed locally), and doesn't need to be shared across multiple users or machines. A local filesystem server or a local git server are canonical stdio use cases — you want the server to have direct access to your local disk, and there's no reason to put a network hop in the way.

stdio's simplicity is also its constraint: the server's lifecycle is tied to the host process that spawned it, and it can only serve the one host that launched it. It is not reachable by anyone else, on this machine or another.

Streamable HTTP: remote, shared

Streamable HTTP is the transport for servers that run independently of any one host — as a standalone deployed service, potentially serving many different hosts and users concurrently. This is the right choice when the server needs to be reachable over a network, when it wraps a resource that shouldn't have credentials distributed to every individual machine that wants to use it (better to centralize the credential in one deployed server), or when multiple team members or multiple applications should share one running server instance rather than each spinning up their own local copy. Streamable HTTP replaced the older HTTP+SSE transport and supports the same duplex streaming needs — server-initiated messages and long-running operations — over standard HTTP.

The deciding questions

Ask: does this server need to run on infrastructure separate from the host's machine? Do multiple people or hosts need to hit the same running instance? Is the resource being wrapped something you'd rather centralize credentials for, rather than distribute? A "yes" to any of these points toward Streamable HTTP. If the server is purely local tooling for one developer on one machine, stdio is simpler, has lower latency, and avoids standing up any hosting infrastructure at all.

Operational differences worth knowing

Beyond the trust and sharing question, the two transports have different operational profiles that scenario questions sometimes lean on. A stdio server's failure mode is local and contained — if it crashes, only the host process that spawned it is affected, and restarting the host typically respawns it. A Streamable HTTP server's failure mode looks like any other remote service outage: it can go down independently of any client, needs its own monitoring, and a network partition can leave a client unable to reach it even though both the host and the server process are individually healthy. Authentication is also asymmetric: a stdio subprocess inherits trust implicitly from having been launched by the host on the same machine, with no separate auth handshake typically required, while a Streamable HTTP server has to authenticate each client independently, since anyone who can reach it over the network is a potential caller. Designing that authentication layer is part of the cost of choosing Streamable HTTP, not an afterthought.

Exam trap A question describes an MCP server that needs to be used by an entire team, each person running their own instance of the host application (Claude Code, Claude Desktop, etc.) on their own laptop, connecting to one shared company database. The trap answer is stdio, reasoning "it's simple and stdio is the default." But since multiple hosts on multiple machines need to reach the same server, and centralizing database credentials in one place is preferable to distributing them to every laptop, Streamable HTTP is correct here. Local-only convenience is not the deciding factor — shared, remote reachability is.

Scenario: a solo developer wants an MCP server that lets Claude Code read and write files in a specific project directory on their laptop. No sharing, no remote access, no credential-centralization concern — the server and host are always on the same machine. stdio is the right call: launch it as a subprocess, communicate over stdin/stdout, done. Reaching for Streamable HTTP here would mean standing up and securing a network-facing service for a capability that never needs to leave the machine.

Try it

Look at the configuration for any stdio-based MCP server you have set up (the command and args used to launch it) and identify what would have to change to serve it over Streamable HTTP instead — specifically, what you would need to add for authentication, since a locally-spawned stdio process inherits trust from being launched by the host, while a network-reachable HTTP server cannot make that assumption.