MCP Transports Explained: stdio vs Streamable HTTP

MCP Transports Explained: stdio vs Streamable HTTP

An MCP client and server need a path to talk. That path is called a transport. Two common choices are stdio and Streamable HTTP. They carry the same MCP messages, but they fit different jobs.

The short rule is simple. Use stdio when one local app starts one local server. Use Streamable HTTP when many users or services need a server over a network.

## What stdio does

Stdio means standard input and standard output. The client starts the MCP server as a child process. It sends JSON-RPC messages into the process and reads replies from it.

This works well for a desktop tool, command-line app, or local coding helper. Setup is small. There is no web endpoint to run. The process also gives each client a natural session.

The tradeoff is reach. A local process is hard to share with a team. Each user may need the same package, runtime, settings, and secrets. Logs can also sit on many laptops.

Use stdio when:

• The client and server run on the same machine.
• One client owns one server process.
• You want a fast local setup.
• You do not need a shared network service.

## What Streamable HTTP does

Streamable HTTP puts the MCP server behind an HTTP endpoint. A client sends MCP messages with HTTP POST. The server can also stream messages back when the session needs it.

This fits remote and shared servers. A platform team can run one service for many users. Normal web controls can sit in front of it, such as TLS, access tokens, rate limits, logs, and a load balancer.

HTTP also adds work. Teams must set timeouts, handle retries, protect the endpoint, and watch network errors. If the server keeps session state, the client may receive an Mcp-Session-Id. Later calls send that ID back. A load balancer must then route the session with care, or the state must live in a shared store.

Use Streamable HTTP when:

• The server is remote or shared.
• Many clients need the same tools.
• Central access rules and audit logs matter.
• The team can run and secure a web service.

The official MCP transport specification gives the wire rules for both choices.

## Side-by-side choice

Question	stdio	Streamable HTTP
Where does the server run?	On the client machine	On a remote or shared host
Who starts it?	The client starts a process	A service platform runs it
Session shape	One process is one natural session	Stateless or tracked with a session ID
Main strength	Small local setup	Shared access and central control
Main risk	Setup and secrets spread to laptops	Auth, retries, scaling, and network failures

## Two setup examples

For stdio, the client config points to a command and its arguments:

{
  "transport": "stdio",
  "command": "python",
  "args": ["server.py"]
}

For Streamable HTTP, the client points to one MCP URL and sends its access token through a safe secret store:

{
  "transport": "streamable-http",
  "url": "https://tools.example.com/mcp"
}

Exact fields differ by SDK. Keep the design choice the same: a local child process or a managed network service.

## Test before you launch

Start with five checks.

1. Identity: Can the server tell which user or agent made the call?
2. Secrets: Are tokens outside source files, logs, and client config shared in chat?
3. Failure: What happens when a process exits or a network call times out?
4. Session: Can a client reconnect, and does state go to the right place?
5. Audit: Can the team see which tool ran, when it ran, and whether it failed?

Add cost to the test. A remote service has hosting and network cost. A local setup has support time and repeated setup work. Count retries and human review too. The cheapest request is not always the cheapest safe result.

Where a gateway fits

As the server list grows, teams need one place to find tools, apply access rules, and read audit events. The Axiom Studio platform describes a governed path for model and tool calls. The Axiom documentation covers the wider product set. Teams that also send model requests can use the LLM Gateway guide and its product page to plan routing, credentials, fallbacks, and usage tracking.

A gateway does not remove transport choices. It makes remote access easier to govern. Keep local stdio for small tools. Move shared tools to Streamable HTTP when the team is ready to own the web service and its controls.

A practical decision

Pick stdio for one user, one machine, and one short path. Pick Streamable HTTP for shared tools, remote access, and central rules. Then test identity, failure, sessions, and audit records before more agents depend on the server.