MCP Transports Explained: stdio, Streamable HTTP, and Legacy HTTP+SSE

MCP is the protocol. The transport is how JSON-RPC messages move between client and server. This page follows the current published specification and official docs — not informal blog summaries.

What the current spec actually defines

As of specification 2025-11-25 — Transports, MCP defines two standard transport mechanisms:

1. stdio — standard input / standard output
2. Streamable HTTP

Clients SHOULD support stdio whenever possible. Clients and servers MAY implement custom transports if they keep the JSON-RPC message format and lifecycle requirements.

The same page states that Streamable HTTP replaces the older HTTP+SSE transport from protocol version 2024-11-05, and includes a backwards compatibility section for mixed old/new deployments.

The architecture overview summarizes the same pair: stdio for local process communication; Streamable HTTP for remote communication (with optional SSE for streaming).

stdio (standard)

From the 2025-11-25 transports spec:

• The client launches the MCP server as a subprocess
• The server reads JSON-RPC from stdin and writes to stdout
• Messages are newline-delimited and MUST NOT contain embedded newlines
• Logging may go to stderr; the server MUST NOT write non-MCP messages to stdout
• The client MUST NOT write non-MCP messages to the server’s stdin

Best for: local integrations on one machine (IDE / desktop hosts spawning tools).

Not by itself: a multi-user shared URL — that is a process tied to the host that launched it.

Official build tutorials stress a related point: on stdio servers, never log to stdout (e.g. avoid console.log / bare print) or you corrupt the stream — see Build an MCP server.

Streamable HTTP (standard, remote-oriented)

From the 2025-11-25 transports spec:

• The server is an independent process that can handle multiple client connections
• Uses HTTP POST and GET
• May use Server-Sent Events (SSE) within this transport to stream server messages
• The server MUST expose a single MCP endpoint path supporting POST and GET (example shape: https://example.com/mcp)
• Client JSON-RPC messages are sent as HTTP POST bodies
• For requests, the server returns either application/json or text/event-stream (SSE); clients MUST support both
• Optional session support via MCP-Session-Id after initialization
• Clients using HTTP MUST send MCP-Protocol-Version on subsequent requests after negotiation

Security requirements called out in the spec for Streamable HTTP implementations include:

• Validate the Origin header (DNS rebinding); invalid Origin → 403
• When running locally, prefer binding to localhost rather than all interfaces
• Implement proper authentication for connections

Best for: remote MCP servers shared across users and machines.

The architecture overview notes that Streamable HTTP supports standard HTTP authentication patterns (bearer tokens, API keys, custom headers) and that MCP recommends OAuth to obtain tokens — see Architecture overview and Authorization.

Legacy HTTP+SSE (replaced, still relevant for compatibility)

Protocol version 2024-11-05 defined HTTP with SSE as a standard remote transport. The current transports document treats Streamable HTTP as the replacement and documents how:

• Servers can still host old SSE + POST endpoints beside the new MCP endpoint
• Clients can probe with InitializeRequest POST and fall back to the old HTTP+SSE handshake on certain HTTP errors

If you maintain old remote servers or clients, read the Backwards Compatibility section on the 2025-11-25 transports page rather than treating “SSE” as a third equal modern standard.

Decision guide (aligned with the docs)

How this relates to MCPLambda

MCPLambda is a hosting product, not the protocol. At deploy time you can select transports the platform supports (including options labeled for stdio, streamable-http, or SSE depending on product configuration). Regardless of process transport, the platform exposes a Deployment URL for clients; stdio processes may be proxied to a web endpoint so clients do not speak raw stdin on a container.

Product docs: Deployment strategies, Connecting AI clients.

When in doubt for protocol behavior, the specification wins over any host’s UI labels.

Worked scenario: The URL config pointed at a stdio server

A developer pastes a localhost command into a remote URL field—or deploys Streamable HTTP but configures Cursor with command/args. Nothing works; everyone blames “MCP.”

You teach the split: stdio = client spawns subprocess; Streamable HTTP = independent HTTP MCP endpoint (current remote standard). Legacy HTTP+SSE exists for compatibility, not as the default for new remotes.

Checklist: pick transport, match host config shape, for HTTP validate Origin and auth, never log on stdout for stdio.

Checklist for this topic

• Use stdio for local single-user integrations
• Use Streamable HTTP for new remote multi-client servers
• Only use legacy HTTP+SSE when compatibility requires it
• Match host config (command vs url) to transport
• HTTP: Origin validation + authentication
• stdio: no non-MCP bytes on stdout

Topic-specific failure modes

Related guides

Connect clients · When to go remote · Spec transports

Sources

• Transports — specification 2025-11-25 (current standard: stdio + Streamable HTTP; Streamable HTTP replaces HTTP+SSE)
• Transports — specification 2024-11-05 (historical HTTP+SSE definition)
• Architecture overview
• Build an MCP server (stdio logging rules)
• Authorization — 2025-11-25

Next steps

• When to leave local MCP
• Connect remote MCP to clients