What you’ll be able to do
- Choose stdio versus HTTP transport based on who runs and reaches the server
- Explain what changes about auth and lifecycle when moving from stdio to HTTP
- Recognize when a shared team tool has outgrown a stdio-based server
What you need to know
Transport is an architecture decision, not a config flag
It's tempting to treat the choice between stdio and HTTP transport as a late detail — pick one, wire it up, move on. It isn't. The transport encodes an assumption about the server's whole lifecycle: who starts it, who can reach it, and what happens when it needs to be shared.
- stdio — the client launches the server as a local subprocess and talks over its stdin/stdout. One process per client, no network exposure, no separate deployment. This is the right shape for a personal dev tool or a server that only ever runs alongside the one client using it.
- HTTP (Streamable HTTP) — the server runs independently, potentially shared by many clients, reachable over a network. This is the right shape the moment more than one person or process needs the same running server.
Picking stdio for something that needs to be shared doesn't just under-perform — it's structurally wrong, because stdio has no concept of "a second client connects while the first is still running." Picking HTTP for a single local dev tool isn't wrong so much as needless: it adds a deployment, a port, and an auth surface for a problem stdio already solves with zero of those.
Auth and lifecycle change with the transport, not just the connection method
A stdio server inherits the identity and permissions of the process that launched it — there's no separate authentication step, because there's no network boundary to authenticate across. That's a feature for a local tool and a liability for anything else: it means stdio has no natural place to enforce "which caller is allowed to do what."
An HTTP server has to solve that problem explicitly, because a network-reachable service has no implicit trust from proximity. This is exactly where teams get caught out: they migrate a working stdio tool to HTTP for sharing, and ship it with no auth layer, because the stdio version never needed one and nobody added the step.
The exam’s favorite trap: shared state, wrong transport
A scenario describing a tool "the whole team uses" or a server that "several agents need to call at once" is describing HTTP transport, full stop — regardless of how the scenario otherwise dresses up the tool's function. A scenario describing "a developer's local coding assistant" or "a tool that only this one agent process uses" is describing stdio. The tool's function is a distractor; the deciding fact is always who else needs to reach it and whether it needs to keep running independently of any one client.
Key concept
stdio and HTTP transport aren’t two ways to say the same thing — they encode who launches the server, who else can reach it, and what has to be true about auth. Choose based on sharing, not habit.
When a scenario's deciding fact is "shared across users" or "reachable by multiple clients," the answer is HTTP transport with an explicit auth layer. When it's "a single local process," the answer is stdio, and adding network auth to it is solving a problem that doesn't exist yet.
Practice scenario
Work it through, then open this
You can’t “just point them at it” — a stdio server is launched and owned by a single client process; there’s no running server to point a second client at. This requires re-architecting the transport to HTTP: a long-running, independently deployed server that multiple clients can connect to, plus an auth layer that stdio never needed because it never had a network boundary to defend.
Build exercise — Decide transport before writing a line of server code
Foundational · 20 min
What you’ll learn
- Reading a scenario for the actual deciding fact (sharing), not the tool’s function
- Naming what auth work HTTP transport adds that stdio never needed
- Recognizing when a stdio tool has outgrown its transport
-
For three MCP server scenarios you can imagine at your own organization, write down whether each is single-client-local or multi-client-shared, and pick a transport for each before considering anything else about the tool.
- Why: Transport should be decided from sharing requirements first — everything else about the server’s design follows from it.
- You should see: A quick, confident stdio/HTTP call for each, made before any implementation detail was considered.
-
For the HTTP case, list what auth mechanism you’d need that the stdio case would never have required.
- Why: This is the concrete cost of “just switching to HTTP” that catches teams who migrate late.
- You should see: An explicit auth requirement (API key, OAuth, session) with no stdio equivalent.
Exam traps
Treating stdio and HTTP as interchangeable with only a syntax difference
They encode different assumptions about lifecycle and reachability, not just a different wire format.
Building a shared, multi-user tool on a stdio server meant for one local process
stdio has no concept of a second client connecting to an already-running server.
Deferring transport choice until after the server’s auth model is designed
Transport determines whether you need an auth model at all — decide it first.
Assuming an HTTP MCP server needs no more security thought than a local one
A network-reachable server has no implicit trust from proximity; auth has to be explicit.
Choosing HTTP for a purely local dev tool out of habit
It adds a deployment, a port, and an auth surface to solve a problem stdio already solves with none of those.