TL;DR
An MCP server can run two ways. stdio launches the server as a local subprocess and talks over standard input/output — fast, simple, single-client. Streamable HTTP runs the server as an independent process reachable over one HTTP endpoint — remote, multi-client, scalable. Same JSON-RPC messages either way, so the tools are portable between them.
The same protocol, two pipes
Discovery and calling (last lesson) define what messages flow: tools/list,
tools/call, and their results, all JSON-RPC 2.0. The transport is how those
messages physically travel between client and server. MCP has two official ones, and
they suit opposite situations.
stdio — local subprocess
With stdio, the client launches the server as a child process and they talk
over its standard input and output streams: the server reads JSON-RPC messages from
stdin and writes them to stdout. No network, no ports.
- Best for: local, single-client tools — a server that wraps your filesystem, a local database, or a CLI on the same machine as the agent.
- Strengths: lowest latency, dead simple, nothing to expose to the network.
- Limits: one client per server process, and the server lives and dies with the agent that spawned it.
Streamable HTTP — remote, multi-client
With Streamable HTTP, the server runs as its own independent process and exposes a single HTTP endpoint that the client POSTs to (with optional Server-Sent Events for streaming responses back). The client connects over the network instead of spawning anything.
- Best for: shared, remote servers — one Help Desk server backing many agents on many machines.
- Strengths: multiple clients at once, scales horizontally, deploy and update the server independently of the agents.
- Limits: you now run a networked service — auth, TLS, and availability are your problem.
Streamable HTTP is the current remote transport; it replaced the older HTTP+SSE transport from the 2024-11-05 spec. If you read about "HTTP+SSE," that's the predecessor.
Analogy
stdio is a walkie-talkie clipped to one person — instant, private, useless to anyone else. Streamable HTTP is a phone number the whole team can call. Same conversation; very different reach.
Choosing a transport
| stdio | Streamable HTTP | |
|---|---|---|
| Where the server runs | Local subprocess | Independent process / remote |
| Clients | One (the spawner) | Many, concurrent |
| Connection | stdin / stdout | One HTTP endpoint (+ optional SSE) |
| Reach for it when | Local, single-user tool | Shared, remote, scalable service |
That's the checkpoint: ten agents on different machines need a server they can all reach over the network — Streamable HTTP. stdio can't serve them because each stdio server is a private subprocess of a single agent; there's no network address for the others to dial.
Common mistake
Assuming the transport changes how you write tools. It doesn't — because both transports carry the same JSON-RPC messages, a server's tool definitions are portable. You can develop a server over stdio locally and later run the very same server over Streamable HTTP for production, without touching the tools.
Key takeaways
Key takeaways
- The transport is how MCP messages travel; the protocol messages are identical.
- stdio: local subprocess, single client, lowest latency, no network.
- Streamable HTTP: independent process, many clients, remote and scalable.
- Tools are portable across transports — develop on stdio, deploy on HTTP unchanged.
Go deeper: the client–server–host shape
MCP defines three roles, and keeping them straight clears up a lot of confusion:
- Host — the application the user interacts with (the agent app, an IDE, a desktop assistant). It manages one or more clients.
- Client — a connector inside the host, with a one-to-one link to a single server. Want to use three servers? The host holds three clients.
- Server — the program that exposes tools/resources/prompts over a transport.
This is why "one client, many servers" from Lesson 1 is precise: each client speaks to exactly one server, but a host can run many clients at once and compose their tools. The transport (stdio or Streamable HTTP) is chosen per client–server pair, so a single host can talk to a local stdio server and a remote HTTP server in the same session. The lab's Help Desk is one such server; the agent host holds the client that connects to it.