MCP Transports

How the client and server exchange JSON-RPC messages. Pick based on deployment.

stdio

• Use when: server runs as a local subprocess of the client (Claude Desktop, Claude Code).
• Client spawns the server, talks via stdin/stdout. JSON-RPC framed line-by-line.
• Easiest dev experience. No ports, no auth.
• stdout = wire — never print or console.log from the server; log to stderr.

SSE (Server-Sent Events) — legacy

• Use when: server hosted as a long-lived HTTP service.
• Client opens an SSE connection to receive messages; posts back via POST.
• Being superseded by Streamable HTTP.

Streamable HTTP (current standard for remote)

• Use when: server is remote / shared / cloud-hosted.
• Single HTTP endpoint. Requests are POSTed; responses can be JSON or SSE stream.
• Supports session resumption.
• The canonical choice for remote MCP servers.

Comparison

Transport	Local	Remote	Multi-client	Auth needed
stdio	✅	❌	❌ (one subprocess per client)	No
SSE	⚠️	✅	✅	Yes
Streamable HTTP	⚠️	✅	✅	Yes

Auth for remote

Remote MCP supports OAuth 2.1 with dynamic client registration. The host kicks off OAuth, persists tokens, attaches them on every request. The server exposes a discovery endpoint with auth metadata.

CCA-F note

Expect questions like "You need to expose your internal MCP server to a fleet of users without each one installing it locally — pick the transport." Answer: Streamable HTTP, with OAuth.

See also

• mcp-overview
• mcp-trust-config