MCP Transports: STDIO vs Streamable HTTP

MCP transports define how protocol messages are framed and delivered. They do not change what tools, resources, prompts, requests, or results mean.

The two standard choices are STDIO for a client-launched local subprocess and Streamable HTTP for an MCP endpoint reached over a network.

TL;DR

• STDIO uses newline-delimited messages over a local subprocess standard streams.
• Streamable HTTP sends client messages as HTTP POST requests to one endpoint.
• HTTP responses can be JSON or a request-scoped Server-Sent Events stream.
• Protocol semantics remain the same across transports.
• Choose based on deployment, identity, scaling, operations, and trust boundaries.

What a transport does

A transport carries UTF-8 JSON-RPC messages. It defines framing, delivery, cancellation, and termination. The core protocol defines message meaning.

This separation lets the same conceptual tool work locally or remotely. Moving a server from STDIO to HTTP should not change the business meaning, although authentication and risk change substantially.

STDIO transport

With STDIO, the client launches the server as a subprocess. The client writes messages to standard input, and the server writes protocol messages to standard output.

Messages are newline-delimited. Standard output must contain only valid MCP messages; logs belong on standard error.

STDIO is a good fit when

• The server runs on the same machine as the host.
• The host controls process startup and shutdown.
• One user or session owns the connection.
• Low local overhead matters.
• The capability needs controlled local access.

STDIO risks

A subprocess can inherit environment variables, filesystem permissions, or executable-search behavior. Use explicit commands, restricted working directories, minimal environment variables, and scoped filesystem access.

Local does not mean trusted. Installing a malicious server can be equivalent to running malicious code on the machine.

Streamable HTTP transport

With Streamable HTTP, the server exposes one MCP endpoint. Each client message is an HTTP POST. A response may be a JSON object or a Server-Sent Events stream scoped to that request.

This supports remote services and standard web infrastructure, but introduces network identity, authorization, routing, origin, rate limiting, tenant isolation, and availability concerns.

Streamable HTTP is a good fit when

• The provider is a managed remote service.
• Many users or clients need access.
• Central deployment and updates matter.
• The organization operates HTTP authentication and observability.
• Long-running or streamed responses are useful.

HTTP risks

Servers must validate origins where required, enforce authentication and authorization, use TLS, protect tokens, limit requests, and isolate tenants. Clients should verify endpoints and avoid forwarding credentials to arbitrary servers.

Comparison

Dimension	STDIO	Streamable HTTP
Location	Local process	Local or remote service
Startup	Client launches server	Independently operated
Framing	Newline-delimited streams	HTTP POST plus JSON or SSE
Typical users	One local client or session	Potentially many clients
Authentication	Process and OS context	HTTP authentication
Scaling	Per machine or session	Service-level scaling
Logging	Standard error	Service logs and tracing
Main danger	Local code and file access	Network, token, and tenant exposure

A coding-assistant example

A filesystem server uses STDIO because it needs the current repository and should stop with the coding session. A remote issue-tracker server uses Streamable HTTP because it is centrally operated for many employees.

The host maintains one client for each. The model may see tools from both while the host applies separate credentials and policies.

Streaming is not unlimited state

Server-Sent Events can deliver a response stream for an HTTP request. Do not confuse streaming with permission to retain unlimited state. Both sides still need identifiers, cancellation, limits, and recovery.

Choosing a transport

Ask:

1. Who operates the process?
2. Which users and tenants share it?
3. Where do credentials live?
4. Which local or network resources can it access?
5. How will it be monitored, updated, cancelled, and recovered?

One local user and a host-owned process usually point to STDIO. A managed multi-user service usually points to Streamable HTTP.

Common mistakes

• Writing debug logs to STDIO output.
• Building transport-specific business semantics.
• Treating local processes as automatically safe.
• Deploying HTTP without tenant authorization.
• Assuming SSE removes timeouts and cancellation.
• Passing secrets through command arguments.

My Take

Transport choice is an operational decision disguised as a protocol setting. Process ownership, identity, blast radius, and observability should decide it.

Continue learning

Read [MCP Architecture](/mcp-architecture/) and [Sandboxing AI Agents](/sandboxing-ai-agents/).

Sources

• MCP specification: Transports
• Latest MCP specification