MCP Transport: stdio, SSE & Streamable HTTP

Three official transports

stdio

Server runs as a subprocess. The host writes to stdin and reads from stdout, one JSON message per line.

Best for: local dev tools, Claude Desktop plug-ins, anything that doesn't cross machine boundaries.

HTTP + SSE

Client POSTs to send; an SSE channel streams server-to-client messages. Older but widely supported.

Best for: remote servers with simple infra; legacy clients.

Streamable HTTP

Single endpoint, bidirectional, supports both streaming and one-shot responses. The current recommendation for remote.

Best for: cloud servers, serverless, anything multi-tenant.

stdio in detail

Each line on stdin/stdout is one JSON-RPC message. stderr is free for the server's own logs — clients will display them but not parse them.

claude_desktop_config.json

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["/path/to/weather_server.py"],
      "env": { "API_KEY": "sk-..." }
    }
  }
}

Streamable HTTP in detail

Single HTTP endpoint serves both POST and (optional) GET for streaming.
Server-Sent Events used for server→client push.
Standardised headers via SEP-2243 (e.g., Mcp-Session-Id).
Supports sessionless mode (SEP-2567) — explicit state handles instead of cookies.

Multi round-trip pattern (SEP-2322)

To avoid forcing transports to support arbitrary server-initiated requests, MCP standardised a multi round-trip pattern: the server returns a "need more info" response, the client gathers the data, and the client re-issues the original request with the extra payload.

Why it matters

Transports only need request-scoped bidirectional flow — no persistent server-push channel required.
The client always has context for what data the server is asking for.
Works in serverless / stateless deployments.

Custom transports

MCP doesn't lock you in. Anything that can carry JSON-RPC messages with framing (length-prefixed, line-delimited, etc.) can host MCP. WebSockets, gRPC, named pipes — all viable for custom integrations.

Quick summary

stdio for local plug-ins; Streamable HTTP for remote
HTTP+SSE still works but is being superseded
Multi round-trip pattern keeps server-initiated requests transport-friendly
Build your own transport if you have a special integration

MCP Transport Layer FAQ

What transports does MCP support?

MCP officially supports three transports: stdio (server as a subprocess, best for local tools), HTTP+SSE (server-sent events for remote servers), and Streamable HTTP (a modern HTTP transport that supports both streaming and non-streaming modes for production deployments).

When should I use stdio vs HTTP transport?

Use stdio when the server runs locally as a subprocess — it's simple, fast, and the default for Claude Desktop integrations. Use HTTP-based transports when the server is remote, deployed in the cloud, or needs to serve multiple clients simultaneously.

What is Streamable HTTP in MCP?

Streamable HTTP is a modern MCP transport that uses standard HTTP POST for requests and optionally SSE for streaming responses. It replaces the older HTTP+SSE transport and is the recommended approach for production remote MCP servers.

Can I implement a custom MCP transport?

Yes. MCP is transport-agnostic by design. You can implement a custom transport (e.g., WebSockets, Unix domain sockets) as long as it correctly frames JSON-RPC 2.0 messages.

Does the transport affect which MCP features are available?

The transport does not affect which MCP protocol features (tools, resources, prompts, sampling) are available. However, streaming features like progress notifications work best with transports that support bidirectional or server-push messaging.

The Transport Layer