MCP supports multiple transport methods because MCP servers live in different places. A code analysis tool running on your laptop has very different communication needs than a shared database server running in your team’s infrastructure. The transport you choose should match where the server runs.
Three transport options
-
stdio — standard input/output. The client launches the MCP server as a child process and communicates through the process’s stdin and stdout streams. No network, no ports, no endpoints. Just pipes.
-
HTTP + SSE — HTTP for client-to-server requests, Server-Sent Events for server-to-client push notifications. This is the web-friendly option for servers accessible over a network.
-
Streamable HTTP — a modern bidirectional HTTP streaming transport that supports both request-response and server-initiated communication. The newest of the three.
All three use JSON-RPC 2.0 for message encoding. Not Protocol Buffers, not custom binary formats — JSON-RPC across the board.
stdio: the default for local servers
Claude Code uses stdio as its primary transport for local MCP servers. The workflow is simple: Claude Code launches the server process, sends JSON-RPC messages through stdin, and reads responses from stdout. No network configuration, no port conflicts, no firewall issues.
This is why stdio is the natural choice for any MCP server that runs on the same machine as the client. It’s the simplest setup — one command to start the process, and communication just works. Cross-platform, no dependencies.
HTTP-based transports: for remote servers
When the MCP server lives on a different machine — a team’s shared database server, a cloud-hosted service, a CI/CD infrastructure tool — you need network communication. That’s where HTTP + SSE and Streamable HTTP come in.
These transports require the server to expose an endpoint and the client to know its URL. More setup than stdio, but necessary when the server isn’t a local process.
Match transport to deployment
The rule is straightforward:
- Local server on the same machine → stdio. Simpler, no network overhead, no port management.
- Remote server on a different machine → HTTP-based transport. Required for network access.
Don’t overthink this. Using HTTP for a local server adds unnecessary complexity (endpoint configuration, port management). Tunneling stdio over SSH for remote access adds unnecessary fragility. Each transport exists for a reason — use it where it fits.
No central registry
MCP servers are configured directly in the client’s configuration file. You specify the command (for stdio servers) or the URL (for HTTP servers). There is no central MCP registry that servers must register with before clients can connect. Discovery is explicit, not automatic.
All transports, same capabilities
A common misconception: that some transports limit which MCP primitives (Tools, Resources, Prompts) are available. They don’t. All three transports support the full MCP protocol. The transport affects how client and server communicate, not what they can do.
One-liner: Use stdio for local MCP servers (Claude Code’s default) and HTTP-based transports for remote ones — all transports support the full protocol over JSON-RPC 2.0, with no registry required.