Wiki · Concept · Last reviewed June 25, 2026

MCP Transports

MCP transports are the Model Context Protocol layer that carries JSON-RPC messages between clients and servers, with different trust boundaries for local subprocesses and HTTP services.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Transports, AI Agents, HTTP, Stdio, Governance

Definition

MCP transports are the connection mechanisms used by the Model Context Protocol to move JSON-RPC requests, notifications, and responses between a client and a server. In the 2025-11-25 specification, MCP messages must be UTF-8 encoded JSON-RPC messages, and the standard transport choices are stdio and Streamable HTTP.

Transport choice is not a cosmetic deployment detail. It decides who launches the server, where credentials live, whether network controls can observe traffic, how sessions are represented, how shutdown works, and what evidence remains when a tool call causes harm.

Two Standard Transports

The transports specification defines stdio, which communicates over standard input and standard output, and Streamable HTTP, which uses HTTP requests against an MCP endpoint. The same page says clients should support stdio whenever possible, and also allows custom transports if they preserve MCP's JSON-RPC message format and lifecycle requirements.

That means "MCP support" is incomplete unless the deployment record names the transport. A local editor subprocess, a remote enterprise connector, and a custom embedded channel may expose similar tools to the model while creating very different operational risks.

Stdio Boundary

With stdio, the client launches the MCP server as a subprocess. The server reads JSON-RPC messages from stdin and writes JSON-RPC messages to stdout. Messages are newline-delimited and must not contain embedded newlines. The server may write UTF-8 logging text to stderr, but the protocol warns that clients should not assume stderr means an error condition.

The security boundary is therefore local process control. A governed host needs to know which executable was launched, with which arguments, environment variables, filesystem permissions, network permissions, working directory, and user account. The official security guidance warns that a proxy architecture that can spawn stdio servers can become an escalation path if a web client is compromised, and recommends sandboxing, filesystem restriction, security logging, and extra authorization for dangerous commands.

Streamable HTTP Boundary

Streamable HTTP makes the MCP server an independent process that can handle multiple client connections. It uses HTTP POST and GET requests, can use Server-Sent Events for streaming server messages, and requires the server to provide a single MCP endpoint path that supports both POST and GET. The 2025-11-25 transport page says Streamable HTTP replaces the older HTTP+SSE transport from the 2024-11-05 protocol version, while also giving backward-compatibility guidance for older clients and servers.

Streamable HTTP adds network-facing duties. The transport specification requires servers to validate the Origin header on incoming connections to reduce DNS rebinding risk, says locally run servers should bind to localhost rather than all network interfaces, and says servers should implement proper authentication for all connections.

Authorization and Sessions

The MCP authorization specification is explicitly transport-scoped. Authorization is optional, but when it is supported, HTTP-based transports should follow the MCP authorization specification. The same page says stdio implementations should not follow the HTTP authorization specification and should retrieve credentials from the environment. Alternative transports must follow established security practices for their own protocols.

Streamable HTTP can also carry an MCP-Session-Id. A server may assign a session ID during initialization; if it does, the client must send that header on later HTTP requests. Clients that no longer need a session should try to terminate it with HTTP DELETE, although the server may reject client termination with HTTP 405. HTTP clients must also include the negotiated MCP-Protocol-Version header on subsequent requests.

Governance Requirements

A transport record should include the server name, transport type, endpoint or executable path, operator, version, launch arguments, environment credential source, requested scopes, network binding, session policy, timeout policy, shutdown path, and logs retained for incident review. For stdio, the record should include process sandboxing and filesystem reach. For HTTP, it should include authentication mode, origin validation, TLS, token audience validation, session ID handling, and endpoint ownership.

Failure Modes

Transport flattening. The interface says "tool" while hiding whether the call went to a local subprocess, a remote service, or a custom channel.

Local proxy escalation. A web compromise reaches a proxy that can spawn stdio servers with user-level permissions.

Session-as-authentication. A system treats MCP-Session-Id as proof of authority instead of separately validating authorization.

Legacy drift. A deployment mixes older HTTP+SSE assumptions with Streamable HTTP behavior and loses message, version, or session evidence.

Source Discipline

Claims about MCP transports should cite the versioned transports page. Shutdown and timeout claims should cite the lifecycle page. Claims about HTTP authorization should cite the authorization page, and claims about local proxy risk should cite the MCP security best-practices page. Do not infer that a product's connector UI follows the protocol unless the vendor documents the actual transport, authorization, and session behavior.

Spiralist Reading

Transport is where invisible agency becomes infrastructure. The user sees a button or a chat turn; the system chooses a subprocess, an endpoint, a credential path, and a log trail.

The Spiralist rule is simple: do not let a transport disappear into the word "integration." A tool boundary that cannot be named cannot be audited. A server that cannot be located cannot be governed.

Open Questions

Sources

Return to Wiki