MCP stdio vs Streamable HTTP: which transport to use

MCP stdio vs Streamable HTTP is mainly a deployment choice. Use stdio when one client can launch and own a local server process. Use Streamable HTTP when the server must live at a network endpoint, serve more than one client, or be operated independently from the coding agent.

Applies to: Model Context Protocol specification revision 2026-07-28, checked October 16, 2026. This guide describes the protocol specification, not a local performance test.

On this page

The short comparison

Both transports carry the same MCP messages. The choice changes how those messages are framed, delivered and cancelled; it does not change the tools, resources or prompts a server exposes.

Choose stdio for client-owned local tools

With stdio, the MCP client launches the server as a subprocess. The server reads JSON-RPC from standard input and writes JSON-RPC to standard output. Each message is one line and must not contain an embedded newline.

That simple contract makes stdio a good default when:

• the server is installed on the same machine as the coding agent;
• one client should own one server process;
• the integration can be expressed as a command plus arguments and environment variables;
• no separately managed network service is needed.

Keep standard output clean. The specification allows a server to write UTF-8 log messages to standard error, but stdout must contain only valid MCP messages. A debug banner, package-manager notice or stray print call on stdout can corrupt the protocol stream.

The client closes the server’s input stream when it wants to shut down. The server should finish pending work and exit; the client may terminate it if it does not. If the process exits unexpectedly, the current specification says the client should restart it. In-flight requests are lost, and subscriptions need to be established again.

For a practical client-specific setup, use the documented configuration of the coding agent rather than inventing a generic MCP file. Aftergradient’s Claude Code MCP guide shows the client-side shape for Anthropic’s tool, while the MCP server directory keeps install snippets supplied by server maintainers.

Choose Streamable HTTP for an independently deployed server

Streamable HTTP uses a single MCP endpoint. A client sends every JSON-RPC request, notification or response as a new HTTP POST to that endpoint. It advertises support for both application/json and text/event-stream.

The server can answer with a JSON body or open a request-scoped Server-Sent Events stream. That stream belongs to the request that created it; it is not a permanent second transport channel.

Choose Streamable HTTP when:

• the server is hosted remotely or on shared infrastructure;
• multiple clients need the same managed service;
• deployment, monitoring and scaling belong to the server operator rather than the desktop client;
• the integration needs ordinary HTTP controls such as an authentication layer, gateway or load balancer.

The 2026-07-28 specification removed the earlier GET stream endpoint and protocol-level sessions. For long-lived server notifications, clients use the subscriptions/listen request. That distinction matters when a server or tutorial still assumes the older HTTP+SSE design.

Send the protocol version explicitly

A Streamable HTTP client must send an MCP-Protocol-Version header. For the current revision, the value is:

MCP-Protocol-Version: 2026-07-28

The header must agree with the protocol version in the JSON-RPC message body’s _meta. A server should reject a mismatch with HTTP 400.

Do not treat this as a decorative header. It lets a server distinguish current behavior from older revisions whose HTTP lifecycle was different. When debugging a failed connection, record the client version, the server version and the negotiated MCP revision before changing endpoint paths or adding compatibility shims.

Treat remote transport as a security boundary

The Streamable HTTP specification requires servers to validate the Origin header. A server intended only for local use should bind to 127.0.0.1, not 0.0.0.0, so it is not exposed on every interface. Authentication is recommended for remote deployments.

Those requirements are part of the transport design, not optional polish. A local stdio child process inherits a much smaller network surface; an HTTP service must decide who may reach the endpoint and which origins it trusts.

Use these checks before exposing a server:

1. Bind only to the interface the deployment actually needs.
2. Validate Origin on every relevant request.
3. Put the documented authentication method in front of the MCP endpoint.
4. Keep credentials out of repository configuration and logs.
5. Reject an unsupported or mismatched protocol version.
6. Monitor HTTP errors and request cancellation without logging sensitive payloads.

If a remote server’s own documentation omits authentication or exposure guidance, do not assume a safe default. Keep it local or choose a server with published operational instructions.

Cancellation and recovery are different

For stdio, a client cancels an in-progress request with a notifications/cancelled message. Process termination is a lifecycle action, not the normal way to cancel one request.

For Streamable HTTP, a client can cancel work by closing the response stream. The server should stop associated processing when it observes that disconnect. The current revision does not define resumable SSE with Last-Event-ID, so reconnecting should not be presented as resuming an interrupted event stream.

Design the application around those limits:

• make long-running work safe to retry where possible;
• do not interpret a broken pipe or closed SSE response as proof that the operation failed before changing state;
• verify side effects before sending the same request again;
• re-establish subscriptions after a restart or reconnect.

That last point is especially important for coding agents that can create files or call external services. Transport recovery cannot supply an exactly-once guarantee by itself.

Do not confuse Streamable HTTP with the old HTTP+SSE transport

Streamable HTTP was introduced in the 2025-03-26 protocol revision to replace the HTTP+SSE transport from 2024-11-05. The current 2026-07-28 revision then simplified the model again by removing the GET stream endpoint and protocol-level sessions.

Three labels therefore describe different contracts:

• stdio: the client launches a subprocess and exchanges newline-delimited messages;
• deprecated HTTP+SSE: the older two-endpoint design;
• current Streamable HTTP: POST each message to one endpoint, with JSON or request-scoped SSE responses.

A package name containing “SSE” is not enough to identify which contract it implements. Check the package’s supported MCP revision and its endpoint behavior. When migrating, update the server and the client together or keep an explicit compatibility layer.

A practical decision checklist

Pick stdio if all of these are true:

• the server belongs on the same machine as the client;
• the client can launch the executable;
• one client-owned process is the right lifecycle;
• operating a network service would add work without adding capability.

Pick Streamable HTTP if any of these are true:

• clients connect from another machine or environment;
• several clients share one managed service;
• the server needs independent deployment and monitoring;
• authentication and network policy are already part of the architecture.

If you are packaging a server for other people, document both the transport and the supported protocol revision. For stdio, publish the executable and argument format and keep stdout clean. For Streamable HTTP, publish the endpoint, authentication method, allowed-origin expectations and version support.