stdio vs Streamable HTTP
What you'll learn
stdio is for tools running on the same machine as one user. Streamable HTTP is for servers serving multiple users or running remotely.
- Two official transports. Closed list. Anything else is wrong.
- stdio = local single-user. Server is a child process; lifecycle bound to client.
- Streamable HTTP = remote / multi-user. HTTP endpoint, streaming response, auth at transport.
MCP defines two official transports: **stdio** and **Streamable HTTP** (the current spec name; older docs and question banks call this 'HTTP+SSE'). They're not interchangeable — each fits a different deployment shape, and the wrong choice creates real operational problems.
**stdio** is the local-machine transport. The MCP client (e.g. Claude Code) spawns the server as a child process and communicates via stdin/stdout. There's no port, no auth surface, no network attack surface; the server's lifecycle is bound to the client's. This is the right transport for local single-user tools — filesystem helpers, git operations, local databases — where 'the server runs alongside the client' is the natural shape.
**Streamable HTTP** is the remote / multi-user transport. The server runs on a host (could be remote, could be containerised, could be shared by multiple clients), exposes an HTTP endpoint, and uses streaming (Server-Sent Events) for the response channel. This is the right transport when the server is shared, lives on a different machine, or needs to outlive the client process. Auth is at the transport layer (OAuth-style flows, headers, mTLS — depends on the deployment).
Decision rule: 'Does the server run on the same machine as the client and only serve that one client?' Yes → stdio. No → Streamable HTTP. The trap is reaching for HTTP because it 'feels more modern' for simple local cases (port management, auth surface, lifecycle complexity for nothing) or reaching for stdio for shared services (you can't share a child process across users).
Key points
- Two official transports. Closed list. Anything else is wrong.
- stdio = local single-user. Server is a child process; lifecycle bound to client.
- Streamable HTTP = remote / multi-user. HTTP endpoint, streaming response, auth at transport.
- Older name for Streamable HTTP: 'HTTP+SSE' — same thing, may appear in older question banks.
Examples
stdio. Server runs as a subprocess of Claude Code; no port, no auth, lifecycle bound to the IDE session. Reaching for HTTP here adds operational overhead for zero benefit.
Streamable HTTP. Multiple clients (multiple devs, possibly CI), runs on a host, needs auth (token or OAuth), needs to outlive any single client. stdio can't share a process across users.
Pitfalls
- Picking HTTP for a single-dev local tool because it 'feels more modern.' You've added port management and auth surface for nothing.
- Picking stdio for a multi-user service. You can't share a child process across users; each client would spawn its own.
- Thinking there's a third option (WebSockets, gRPC, named pipes). The list is closed.
Source notes: 00-academy-basics/notes/05-mcp-intro.md
Ask Claude
Build a prompt with this lesson + your question, copy it, and open the Claude Project in a new tab.