Evidence-first authority page
MCP Stdio vs. Streamable HTTP: Choosing a Transport
A direct comparison of MCP's two transports, with concrete guidance on which to choose for a given deployment.
Direct answer
Choose stdio for a server that only needs to run on the same machine as its client, with no network exposure and no auth to build; choose Streamable HTTP when multiple clients need to share one running server instance, or when the server must run independently of any single client's lifecycle.
Last reviewed 2026-08-29
This page remains noindex while its page-level source receipts are completed and verified. It is available for review, not presented as publication-ready authority.
Side-by-side
- stdio — local subprocess, no network exposure by default, simplest to set up, one client per server instance.
- Streamable HTTP — network-accessible, supports multiple concurrent clients, requires you to handle authentication, TLS, and rate limiting yourself.
- stdio has effectively no deployment cost beyond the client machine; Streamable HTTP requires hosting, uptime monitoring, and ongoing operational ownership.
A simple decision rule
If you can answer 'yes' to 'will this always run on the same machine as its one client,' use stdio — it's simpler and has a smaller security surface by default. The moment the answer becomes 'no' for any reason (a team needs shared access, the server needs to run as a persistent service), Streamable HTTP is the transport built for that case, with the added responsibility that comes with it.