Backend
MCP Transports: stdio vs Streamable HTTP
August 20268 min read
The Model Context Protocol defines stdio and Streamable HTTP. stdio runs the server as a local subprocess that communicates over standard input and output, while Streamable HTTP runs it as a remote service reached over the network with streaming responses. The protocol messages are identical across both; only where the server runs and how it is reached changes.
Use stdio for local developer tools, filesystem access, and anything that should run privately on a single machine, since it needs no network, no port, and no separate deployment. Choose Streamable HTTP only when a server genuinely needs to be shared, hosted, or reached by many clients over the network.
A Streamable HTTP server is an exposed network service and must be secured like one. The specification highlights real risks, including validating the request origin, avoiding token passthrough, and blocking access to internal metadata addresses. Never ship a remote MCP server without authentication and origin validation in place.
No. The transport is not the protocol, so whichever you pick, the server exposes the same tools, resources, and prompts and the client makes the same calls. Switching transports later mostly changes configuration and deployment, not the server logic, so you can develop locally over stdio and host the same code over HTTP later.
With Streamable HTTP, yes: a single deployed service can serve many clients and users at once, which is exactly what a hosted integration needs. With stdio, each client launches its own private subprocess, so there is no sharing across clients or machines.
Key Takeaway
The Model Context Protocol supports two standard transports. stdio runs a server as a local subprocess that talks over standard input and output, ideal for local tools. Streamable HTTP runs the server as a remote service reachable over the network, suited to shared and hosted deployments. The protocol messages are identical; only the pipe changes.
When you connect an MCP server to a client like Claude Code, you choose how the two processes talk. That choice is the transport, and the protocol defines two: stdio and Streamable HTTP. The messages they carry are the same remote procedure calls, so the decision is really about where your server runs and who needs to reach it.
Getting the transport right early saves pain later, because it shapes deployment, authentication, and how many clients a single server can serve. This comparison explains what each transport does, shows the client configuration for both, and gives a rule of thumb for choosing between them.
| Dimension | stdio | Streamable HTTP |
|---|---|---|
| Where the server runs | Local subprocess on the same machine | Remote service over the network |
| Communication channel | Standard input and output streams | HTTP requests, with streaming responses |
| Setup | Point the client at a command to launch | Point the client at a URL endpoint |
| Authentication | Inherits the local user, no network auth | Needs proper network auth, such as tokens |
| Multiple clients | One subprocess per client | One server can serve many clients |
With the stdio transport, the client launches your server as a child process and exchanges messages over its standard input and output. There is no network, no port, and no listener; the pipe is the operating system connection between two processes on the same machine. That makes it the simplest way to run a server for local tools and files.
Configuring it means telling the client what command to run. A local server registered by command looks like this:
{
"mcpServers": {
"local-fs": {
"command": "node",
"args": ["./dist/server.js"]
}
}
}The Streamable HTTP transport runs your server as a standalone service that clients reach over HTTP, with responses that can stream back incrementally. You point the client at a URL instead of a command:
{
"mcpServers": {
"remote-api": {
"type": "http",
"url": "https://mcp.example.com/mcp"
}
}
}Because it is a real network service, one deployment can serve many clients and many users at once, which is what you want for a hosted integration. It also inherits every concern of exposing a service on a network, so authentication and origin checks move from optional to mandatory.
Start local with stdio while you build and test, then move to Streamable HTTP only when a server genuinely needs to be shared or hosted. Developing against a subprocess removes network and auth from the loop, so you debug the protocol first and the deployment later.
The decision follows from where the server needs to live and who must reach it:
A remote MCP server is an exposed service and must be secured like one. The specification calls out real risks, including validating the request origin, avoiding token passthrough, and blocking access to internal metadata addresses. Never ship a Streamable HTTP server without authentication and origin validation in place.
It helps to remember that the transport is not the protocol. Whichever you pick, the server exposes the same tools, resources, and prompts, and the client makes the same calls. Switching transports later mostly changes configuration and deployment, not the server logic you wrote.
That separation is deliberate. It lets you develop a server locally over stdio and later host the identical implementation over HTTP for a wider audience, without rewriting how the tools work. Choose the transport for today's need and know the door to the other stays open.
stdio and Streamable HTTP are two pipes for the same MCP messages: one local and simple, one remote and shareable. Start local, graduate to HTTP when sharing demands it, secure anything you expose, and let where the server must live make the call.