This comparison is part of our MCP comparisons, within The MCP Guide. Facts are checked against each vendor's own documentation and pricing pages on the date shown.
Pick stdio when the MCP server runs on the same computer as the AI app and serves one person. Pick Streamable HTTP when the server runs on the web and many users or apps connect to it. The tools, resources and prompts work the same on both, so the choice is about where the server lives, not what it can do.
Checked against: the MCP transports overview, the stdio page and the Streamable HTTP page of the 2026-07-28 specification, read on 28 October 2026.
A transport is the delivery layer between an MCP client (the AI app) and an MCP server. The 2026-07-28 spec defines exactly two standard ones. This page compares them side by side for teams deciding how to ship or install a server.
Key Takeaways
- stdio runs the server as a child process of the AI app and passes messages over standard input and output.
- Streamable HTTP runs the server as an independent web service with one endpoint that accepts HTTP POST.
- Both carry the same JSON-RPC messages, so server features do not change with the transport.
- The authorization spec applies to HTTP transports; stdio servers should read credentials from the environment instead.
- The 2026-07-28 spec removed sessions and the GET stream from Streamable HTTP, which makes remote servers easier to scale.
At a glance
| stdio | Streamable HTTP | |
|---|---|---|
| Where the server runs | On the user's machine, launched by the client | As an independent process, usually hosted |
| How messages travel | One JSON-RPC message per line on stdin and stdout | One HTTP POST per message to a single MCP endpoint |
| How replies arrive | Lines on stdout, all on one shared channel | A JSON object or an SSE stream scoped to that request |
| Request metadata | Inside the JSON body only | Body plus required headers (Mcp-Method, Mcp-Name for named calls) |
| Cancelling a request | Send notifications/cancelled | Close that request's response stream |
| Sign-in | Credentials from the environment | OAuth-based authorization spec (SHOULD) |
| Users per server | One client process | Many clients |
| Logging | stderr | Not defined by the transport; the spec suggests OpenTelemetry |
| Status in 2026-07-28 | Standard | Standard |
How stdio works
The stdio page says "the client launches the MCP server as a subprocess." The server reads JSON-RPC messages from stdin and writes them to stdout. Messages are separated by newlines and must not contain embedded newlines.
Only valid MCP messages may go to stdout. The server may write logs to stderr, and the client "SHOULD NOT assume stderr output indicates error conditions."
Shutdown is simple. The client closes the server's input stream, waits, and force-stops the process if needed. If the server crashes, the spec says the client "SHOULD restart it," and because the protocol is stateless, lost requests can just be retried. Our stdio transport reference covers the details.
How Streamable HTTP works
In Streamable HTTP, the server "operates as an independent process." It exposes one path, the MCP endpoint, and every client message is a new HTTP POST to it. For a request, the server answers with either application/json or a text/event-stream (Server-Sent Events, or SSE) stream for that one request, and "the client MUST support both."
The 2026-07-28 revision changed the transport a lot. The changelog lists the removal of protocol-level sessions and the Mcp-Session-Id header, the removal of the HTTP GET stream, and the removal of stream resumability. Long-lived change notifications now use a subscriptions/listen request. Read our Streamable HTTP reference for the header rules.
Where stdio is stronger
- No network exposure by default. Messages stay in a pipe between two processes on one machine. The security best practices page tells local server authors to "use the
stdiotransport to limit access to just the MCP client." - Simple credentials. The authorization spec says stdio implementations "SHOULD NOT follow this specification, and instead retrieve credentials from the environment." An API key in an environment variable is the normal pattern.
- Access to local resources. A local server can read project files, run a local database or drive a browser on your machine.
- Nothing to host. There is no server bill, domain or TLS certificate. The AI app starts and stops the process.
- One channel, easy debugging. Everything flows on one stream, and logs stay on
stderr.
Where Streamable HTTP is stronger
- Many users, one install. A vendor hosts the server once, and users connect by URL instead of installing software.
- Real sign-in. HTTP servers can use OAuth, so each user grants access with their own account and scopes.
- Scaling. With sessions gone, the 2026-07-28 release post says every request is self-describing, "so any request can land on any instance behind a plain round-robin load balancer."
- Gateways and routing. The required
Mcp-MethodandMcp-Nameheaders let proxies and gateways route or filter calls without parsing the body. - Works in web and mobile clients. Hosted AI apps such as browser-based chat tools cannot launch a process on your laptop, so they need a URL.
Pricing
Both transports are part of an open protocol, so there is no fee to use either one. The costs differ in practice. stdio has no hosting cost but needs software on every user's machine. Streamable HTTP needs hosting, a domain, TLS and an auth setup, which you pay for whether you build it yourself or use a platform. For hosting options, see Cloudflare Workers vs Vercel for MCP hosting.
Security and admin controls
The threats differ by transport.
stdio risks. A local server is a program that runs with the same rights as the AI app. The security best practices page warns about malicious startup commands in client configs and says one-click installs "MUST implement proper consent mechanisms," including showing "the exact command that will be executed, without truncation." It also recommends sandboxing local servers. Our guide to sandboxing local MCP servers explains how.
Streamable HTTP risks. The spec says servers "MUST validate the Origin header on all incoming connections" and return HTTP 403 for an invalid one. When running locally they "SHOULD bind only to localhost," and they "SHOULD implement proper authentication for all connections." Skipping these opens the door to DNS rebinding and exposed local servers.
Admin view. For IT teams, Streamable HTTP is easier to govern centrally. Traffic passes through URLs you can log, put behind a gateway and revoke per user. stdio servers are spread across laptops, so control depends on device management and an approved-server list.
Which to choose
Pick stdio if:
- The server needs local files, a local browser or tools on the user's machine.
- You are building a developer tool installed with a package manager.
- One person uses it and an environment-variable API key is acceptable.
- You want the smallest possible attack surface for a personal tool.
Pick Streamable HTTP if:
- You are a SaaS company exposing your product to AI apps.
- Users should sign in with their own accounts through OAuth.
- You need web or mobile clients to connect without installing anything.
- IT wants central logging, gateways and per-user revocation.
Offer both if your users split between developers and business users. Many servers ship a local package for developers and a hosted URL for everyone else. The messages are the same, so the server logic can be shared. The spec allows custom transports too, but they must keep the JSON-RPC format, and byte-stream ones "SHOULD reuse the stdio framing."
Next step
If you are planning a server, decide the transport first, because it shapes auth, hosting and security work. eSEOspace builds both kinds through our MCP development service. Browse more MCP comparisons.
Frequently asked questions
Do tools work differently on stdio and Streamable HTTP?
No. The transports overview says a transport defines how messages are framed and delivered, not what they mean. A tools/call request looks the same on both. Only the envelope changes, such as the HTTP headers on Streamable HTTP.
Can a Streamable HTTP server run on my own laptop?
Yes. The spec covers local HTTP servers and says they should bind only to localhost and validate the Origin header. In most local cases stdio is simpler and exposes less, which is why the security guidance favors it for local-only servers.
Does stdio need OAuth?
No. The 2026-07-28 authorization spec says stdio implementations should not follow it and should read credentials from the environment instead. That usually means an API key or token set in the client's server config.
Is HTTP+SSE a third option?
Not for new work. HTTP+SSE was the original remote transport from 2024-11-05. It is listed in the spec's deprecated features registry with Streamable HTTP as the migration path. See SSE vs Streamable HTTP.
