MCP transports explained: stdio vs SSE vs Streamable HTTP

The three transports at a glance

stdio: the local transport

With stdio, the MCP client launches your server as a subprocess and exchanges JSON-RPC messages over stdin and stdout. There is no port, no TLS, no authentication — the security boundary is your operating system's process model. That is exactly right for tools that live on your own machine: filesystem helpers, local database access, developer utilities.

The limitation is structural. A stdio server is bound to one machine and one client process. You cannot share it with a teammate, install it on a phone, or point ChatGPT's web app at it. It also means every user has to install a runtime (Node, Python, Docker) and keep the server updated themselves.

HTTP+SSE: the deprecated remote transport

The first remote transport (protocol version 2024-11-05) paired two endpoints: the client opened a long-lived Server-Sent Events stream to receive messages, and sent its own messages to a separate HTTP POST endpoint the server advertised over that stream.

This design turned out to be hostile to real infrastructure:

• Load balancers had to pin the SSE stream and the POST endpoint to the same backend instance, defeating horizontal scaling.
• Serverless platforms bill and time out on connection duration; a permanently open SSE stream is the pathological case.
• Proxies and firewalls routinely buffer or kill long-lived streams, producing connections that look healthy but deliver nothing.

Spec revision 2025-03-26 replaced HTTP+SSE with Streamable HTTP. The old transport still works where both sides keep supporting it, but the direction is one-way: platforms have been announcing removal dates through 2026 — Atlassian's Rovo MCP server, for example, announced an HTTP+SSE cutoff of June 30, 2026. New servers should not ship it.

Streamable HTTP: the current standard

Streamable HTTP collapses everything onto a single MCP endpoint. The client sends JSON-RPC messages as ordinary HTTP POST requests. For a simple request, the server answers with a plain JSON response — request in, response out, connection closed. When the server needs to push several messages for one request (progress updates, notifications), it can upgrade that specific response to an SSE stream. Streaming becomes an option per response, not a mandatory architecture.

• Stateless requests by default — load balancers and serverless platforms just work.
• One URL to configure, secure and monitor instead of two coupled endpoints.
• Sessions are explicit (an Mcp-Session-Id header) instead of implied by a held-open socket, so a server can resume or reject them deliberately.
• Standard HTTP auth applies — which is what makes OAuth 2.1 integration clean.

A remote server entry in a client config is now just a URL:

{
  "mcpServers": {
    "my-tool": {
      "url": "https://my-tool.mcp.buildmymcpserver.com/mcp",
      "auth": "oauth2"
    }
  }
}

Choosing a transport

• Only you, on your machine → stdio. Zero infrastructure, strongest isolation.
• Anyone else, any other machine, any hosted client → Streamable HTTP over TLS, with OAuth 2.1 in front of it. This is the only current answer for servers that Claude Desktop, Cursor and ChatGPT install over the internet.
• Existing HTTP+SSE server → migrate. The usual path is to serve the new single MCP endpoint alongside the legacy pair during a transition window, then drop the legacy endpoints once your clients are confirmed on the new transport.

FAQ