MCP Transport
What is an MCP transport?
An MCP transport is the binding that carries Model Context Protocol messages between an [MCP client](/glossary/mcp-client/) and an [MCP server](/glossary/mcp-server/). It defines how messages are framed and delivered and how connection-level events such as cancellation or termination are represented.
Transport answers “How do the messages move?” The core protocol answers “What do the messages mean?”
Standard transport bindings
The current MCP specification defines standard bindings for:
- stdio, where a client launches a local subprocess and exchanges newline-delimited messages through standard input and output;
- Streamable HTTP, where messages are sent to an MCP endpoint using HTTP and responses can use a JSON object or a request-scoped server-sent event stream.
Custom transports are possible when they satisfy the protocol’s transport requirements. The same MCP capabilities—such as tools, resources, and prompts—retain their semantic meaning across bindings.
Simple example
A desktop assistant launches a local filesystem server over stdio because both run on the same machine. The same assistant connects to a hosted CRM server over Streamable HTTP. The transport setup differs, but both servers can expose MCP tools using the protocol’s tool semantics.
Transport versus protocol semantics
Transport does not decide which tools exist, how resources are identified, what prompt templates return, or whether a user approves an action. Those belong to MCP feature semantics or application policy.
Likewise, choosing HTTP does not make an ordinary API endpoint an MCP server. The endpoint must still understand the required MCP message structures and behavior.
Transport can affect operational qualities such as deployment, authentication environment, network exposure, [latency](/glossary/latency/), and failure handling. It should not be described as changing what an MCP tool or resource means.
Why it matters
Keeping transport separate from semantics allows MCP integrations to fit different environments without redefining their capabilities. Local subprocesses and remote services have different security and reliability concerns, so builders must choose controls appropriate to each.
For example, a local process may need strict command and filesystem restrictions, while a remote transport needs secure network communication, authentication, timeouts, and protection against untrusted endpoints.