MCP
4 / 6
MCP 3 min

Transport Layers: stdio vs SSE

Local vs remote MCP servers and when to choose each transport option.

MCP separates the protocol (JSON-RPC messages) from the transport (how those messages physically travel). The two you will meet in practice are stdio and Streamable HTTP/SSE.

stdio. The host spawns the server as a child process and writes/reads JSON-RPC messages over its stdin/stdout pipes. No network stack, no ports, no TLS. This is what `hello-mcp-server`, `github-server`, and `postgres-server` all use in the companion repo, and it is the right default for anything running on the user's own machine.

Streamable HTTP / SSE. The server runs as its own long-lived process (or a cloud service), and the client connects over HTTP, receiving a stream of events. This is what you need when the server has to outlive the host, serve multiple clients at once, or run somewhere the host cannot spawn a process, like a shared team deployment.

The Real Tradeoff
stdio: near-zero latency (it's a local pipe), trivial to secure (no exposed port, inherits the host's OS permissions), but tied to one host process and dies when that process closes. Streamable HTTP: network round-trip latency, needs its own auth (bearer tokens, OAuth), but supports many simultaneous clients and can be centrally deployed, monitored, and scaled independently of any single host.
Quick Decision Rule
Use stdio when the server runs on the same machine as the host and only that host needs it. Use Streamable HTTP when the server must be shared across multiple users, kept running independently, or deployed as its own service.
USB Cable vs Network Socket

Stdio is like plugging in a USB cable directly to your machine. Streamable HTTP is like connecting to a service over the network where many clients can access the same endpoint.

What's Next
Transport gets your messages there. Security decides what happens once a malicious or buggy message arrives. That's next.