MCP Transports: stdio and Streamable HTTP Explained

What MCP transports are

MCP transports decide how a client and a server exchange messages, and the choice also decides where the server can run. A local server runs as a process on the same machine as the client. A remote server runs behind a network address.

MCP transports are the mechanisms that carry JSON-RPC messages between an MCP client and an MCP server. The specification defines two standard transports: stdio, where the client launches the server as a local subprocess, and Streamable HTTP, where the server runs as a remote HTTP endpoint. Protocol semantics are identical on both.

stdio: the local transport

In stdio, the client starts the MCP server as a subprocess and the two exchange messages over its standard streams. The server reads JSON-RPC from stdin and writes to stdout, one message per line, with no embedded newlines. It may write logs to stderr, and the client may capture, forward or ignore them.

The server must not write anything to stdout that is not a valid MCP message, so a stray debug print is a protocol violation. The 2025-06-18 specification says clients SHOULD support stdio whenever possible. The 2026-07-28 stdio page keeps the same framing and defines shutdown: the client closes the server's input, waits for it to exit, and force-terminates the process only if it does not.

Claude Code's MCP reference gives this form for a local server:

claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable -- npx -y airtable-mcp-server

Claude Code sets CLAUDE_PROJECT_DIR in the server's environment to the project root, so a server can resolve project paths without depending on its working directory.

Streamable HTTP: the remote transport

Streamable HTTP replaced the HTTP+SSE transport from protocol version 2024-11-05, and it was introduced in the 2025-03-26 revision. The 2026-07-28 revision changed its behavior. The endpoint accepts POST, and each JSON-RPC request is its own HTTP POST. The server answers with one JSON object, or with a Server-Sent Events stream scoped to that request.

Under the 2025-06-18 revision, the single endpoint accepted both POST and GET. The server had to validate the Origin header and should bind to localhost when it runs locally.

Headers a 2026-07-28 client sends

Every POST carries an MCP-Protocol-Version header that must match the version in the request body's _meta. Every request carries Mcp-Method, and requests that name a tool, resource or prompt also carry Mcp-Name. If a header does not match its body value, the server returns HTTP 400 with the HeaderMismatch error, code -32020.

Claude Code's MCP reference recommends HTTP for remote servers and gives this form:

claude mcp add --transport http notion https://mcp.notion.com/mcp

Claude Code also accepts streamable-http as an alias for http in JSON configuration, so a block copied from a server's documentation works without edits.

What's new (as of 6 October 2026)

The current specification revision is 2026-07-28, which the specification site marks as the latest. These changes touch transports, as listed in the changelog:

• Protocol-level sessions and the Mcp-Session-Id header are removed from Streamable HTTP. Servers that need state across calls pass explicit handles as tool arguments.
• The HTTP GET endpoint is removed. Change notifications move to a subscriptions/listen request.
• SSE resumability is removed. The Last-Event-ID header no longer applies, and a broken response stream loses the in-flight request, which the client re-issues with a new request ID.
• Streamable HTTP POST requests must carry the Mcp-Method header, and Mcp-Name where the method names a tool, resource or prompt.
• HTTP+SSE is reclassified as Deprecated, and the revision adopts a feature policy with a minimum twelve-month deprecation window.

Which transport to choose

Choose stdio for a server that runs on the same machine as the client and works with local files or local tools. Choose Streamable HTTP for a server that is hosted or shared over a network. The specification says new implementations should not adopt deprecated features, so a new server should not start on HTTP+SSE.

AI Agents Listing publishes about 604 MCP servers in its MCP servers directory, where you can compare them before you pick one.

Key takeaways

• MCP transports carry messages only, and protocol semantics are identical on stdio and Streamable HTTP.
• stdio runs the server as a subprocess and exchanges newline-delimited JSON-RPC over stdin and stdout.
• The 2026-07-28 revision removes the GET endpoint, protocol-level sessions and SSE resumability from Streamable HTTP.
• Claude Code adds a remote server with claude mcp add --transport http and a local one with --transport stdio.
• HTTP+SSE is Deprecated in the 2026-07-28 revision, and new implementations should not adopt it.

FAQ

Which MCP transport should a local server use?

Use stdio. The client launches the server as a subprocess, so no network endpoint is involved. The 2025-06-18 specification says clients SHOULD support stdio whenever possible.

Does Streamable HTTP still use Server-Sent Events?

Yes, for the response to a single request. The server answers with a JSON object or with an SSE stream scoped to that request. The 2026-07-28 revision removed SSE resumability, so a client whose stream breaks must send the request again under a new request ID.

Is HTTP+SSE still supported?

For compatibility, yes. The 2026-07-28 revision marks HTTP+SSE as Deprecated. The 2025-06-18 backwards-compatibility section says servers that want older clients can keep the old SSE and POST endpoints alongside the MCP endpoint. Claude Code's reference also marks SSE as deprecated and recommends HTTP for remote servers.