Transports & The Wire

Topics We'll Cover

• Why MCP Needs More Than One Transport
• stdio — The Default for Local Servers
• HTTP+SSE (Legacy) — What It Did and Why It Died
• Streamable HTTP — Single Endpoint, Two Modes
• Sessions and the Mcp-Session-Id Header before 2026-07-28
• Resumable Streams — Last-Event-ID in Practice before 2026-07-28
• Streamable HTTP in 2026-07-28 — Stateless POSTs and subscriptions/listen 2026-07-28
• Auth, Origin, and the DNS-Rebinding Trap
• Wire Capture — A Real Session, Byte by Byte before 2026-07-28
• Wire Capture in 2026-07-28 — No Session at All 2026-07-28
• Choosing a Transport in 2026

Why MCP Needs More Than One Transport

The protocol is transport-agnostic by design — the JSON-RPC envelopes don't care how they got there. But the practical deployments split cleanly into two worlds with different constraints, and the spec ships first-class transports for each.

stdio — The Default for Local Servers

The host launches the server as a subprocess and pipes stdin/stdout. That's it. Each side reads JSON-RPC messages from one stream and writes to the other.

Framing rules — line-delimited JSON

• Each message is a single JSON object on a single line, terminated with \n (LF). No embedded newlines — if your JSON is pretty-printed, you've corrupted the stream.
• STDOUT carries protocol only. One stray print() call in your server will desynchronise the client's parser.
• STDERR carries logs only. The host MAY display it for debugging, but it must not contain JSON-RPC messages.
• Encoding is UTF-8. Messages must not contain embedded NULs.
• Since 2025-06-18, JSON-RPC batches (a top-level array) are no longer permitted on any transport, including stdio.

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"x","version":"0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}

{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}

The framing rules are unchanged in 2026-07-28. What changed is the first message: there is no initialize; a client may open with any request carrying _meta, or with server/discover, which also tells it whether the subprocess is a legacy (handshake-only) server. The process is no longer a session: unrelated requests may interleave on it.

Source: MCP specification 2026-07-28 — stdio; Discovery; Overview: statelessness (accessed 2026-10-08).

How the host configures stdio servers

The host's config typically maps a name to a command line and an environment. Claude Desktop's claude_desktop_config.json is representative:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"],
      "env": { "DEBUG": "1" }
    },
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite", "--db-path", "/tmp/test.db"]
    }
  }
}

HTTP+SSE (Legacy) — What It Did and Why It Died

The original web transport, shipped with 2024-11-05 and deprecated in 2025-03-26. Worth understanding because (a) servers in the wild still use it and (b) it explains the design pressure that produced Streamable HTTP.

Two endpoints, two directions

The first message on /sse was a synthetic endpoint event telling the client which URL to POST to. Every subsequent server-to-client message arrived as an SSE data: event on the same stream.

event: endpoint
data: /messages?session_id=8c8a7b...

event: message
data: {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05",...}}

event: message
data: {"jsonrpc":"2.0","method":"notifications/tools/list_changed"}

Why it died

• Two endpoints meant two failure modes. If the SSE socket dropped while a POST was in flight, the response could never reach the client.
• No clean resumability. Reconnecting /sse meant losing every message between the disconnect and the reconnect.
• Awkward for stateless infra. Load balancers that serialise on session IDs need a single canonical URL, not a flow that bounces between two paths.
• SSE's request/response asymmetry made it impossible for a single POST to receive a streamed response (e.g. progress notifications during a long tool call).

Streamable HTTP — Single Endpoint, Two Modes

Introduced in 2025-03-26. One URL, typically /mcp or /, that accepts both POST and GET (before 2026-07-28; from 2026-07-28 only POST, see slide 06b). The server picks per request whether to respond with a single JSON body or to upgrade to an SSE stream.

Why two response modes for one POST?

The same call can need either shape. tools/list takes microseconds and returns a single JSON object. tools/call on a long-running operation may want to emit notifications/progress for two minutes before returning the final tool result. The server signals which mode by setting the Content-Type header on the response.

POST /mcp HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbG...
MCP-Protocol-Version: 2025-06-18
Mcp-Session-Id: 1d31a3f4-...
Accept: application/json, text/event-stream
Content-Type: application/json

{"jsonrpc":"2.0","id":42,"method":"tools/call",
 "params":{"name":"long_query","arguments":{"sql":"..."}}}

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

event: message
id: 1
data: {"jsonrpc":"2.0","method":"notifications/progress",
       "params":{"progressToken":"abc","progress":0.25}}

event: message
id: 2
data: {"jsonrpc":"2.0","method":"notifications/progress",
       "params":{"progressToken":"abc","progress":0.75}}

event: message
id: 3
data: {"jsonrpc":"2.0","id":42,"result":{...}}

In 2026-07-28 the same POST drops Mcp-Session-Id and the SSE id: lines, and adds Mcp-Method: tools/call and Mcp-Name: long_query; the body carries _meta with the protocol version, which must match the MCP-Protocol-Version header.

Source: MCP specification 2026-07-28 — Streamable HTTP; Streamable HTTP: earlier revisions (accessed 2026-10-08).

Sessions and the Mcp-Session-Id Header before 2026-07-28

Sessions are optional but standardised. A server that wants to remember client state across requests opts in by returning Mcp-Session-Id on the initialize response.

Server-side state semantics

• The session ID MUST be a globally unique, cryptographically random value — not a sequential counter.
• If the server has invalidated the session (timeout, redeploy, eviction), it returns 404 Not Found on requests carrying that ID. The client MUST then re-initialize.
• The session is the canonical place to attach: capability negotiation results, the agreed protocol version, the OAuth principal, scratch caches, subscription lists.
• For horizontally-scaled servers, sticky-routing on this header is the simplest correct approach — or store session state in shared infrastructure.

Resumable Streams — Last-Event-ID in Practice before 2026-07-28

SSE has had a built-in resumption mechanism since HTML5: when the browser reconnects to a stream, it sends the last id: it saw in the Last-Event-ID request header. The server then replays everything after that ID. MCP exploits this directly.

Streamable HTTP in 2026-07-28 — Stateless POSTs and subscriptions/listen 2026-07-28

The transport keeps its name and its single endpoint, but loses everything that tied a client to one server instance. Every JSON-RPC message is its own POST; each request gets either one JSON body or an SSE stream scoped to that request. Any replica behind a plain load balancer can answer any request.

POST /mcp HTTP/1.1
Accept: application/json, text/event-stream
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: subscriptions/listen

{"jsonrpc":"2.0","id":1,"method":"subscriptions/listen","params":{
  "_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28",
           "io.modelcontextprotocol/clientCapabilities":{}},
  "notifications":{"toolsListChanged":true,
                   "resourceSubscriptions":["file:///project/config.json"]}}}

HTTP/1.1 200 OK
Content-Type: text/event-stream

data: {"jsonrpc":"2.0","method":"notifications/subscriptions/acknowledged",
       "params":{"_meta":{"io.modelcontextprotocol/subscriptionId":1},
                 "notifications":{"toolsListChanged":true,
                   "resourceSubscriptions":["file:///project/config.json"]}}}

data: {"jsonrpc":"2.0","method":"notifications/resources/updated",
       "params":{"_meta":{"io.modelcontextprotocol/subscriptionId":1},
                 "uri":"file:///project/config.json"}}

Source: MCP specification 2026-07-28 — Streamable HTTP; Subscriptions; Key changes (accessed 2026-10-08).

Auth, Origin, and the DNS-Rebinding Trap

Three headers carry all the security weight at the transport boundary:

The DNS-rebinding attack on local HTTP servers

A surprising number of MCP servers expose Streamable HTTP on http://127.0.0.1:PORT for development. Without an Origin check, any web page the user visits can issue fetch() calls against that loopback port using DNS rebinding (resolve attacker.com first to a public IP, then to 127.0.0.1). The result: a webpage drains your tokens.

// 1. Bind explicitly to loopback, not 0.0.0.0
server.listen(PORT, "127.0.0.1");

// 2. Reject requests with foreign Origin
const ALLOWED = new Set(["http://localhost", "app://obsidian.md", ...]);
app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (origin && !ALLOWED.has(new URL(origin).origin))
    return res.status(403).end();
  next();
});

Source: MCP specification 2026-07-28 — Streamable HTTP: security and protocol version header (accessed 2026-10-08).

Wire Capture — A Real Session, Byte by Byte before 2026-07-28

Protocol version 2025-06-18. Annotated TCP-level trace of a Streamable HTTP session: handshake, a tool list, a streamed tool call, a server-initiated notification, and a clean shutdown.

POST /mcp HTTP/1.1
Host: search.acme.io
Authorization: Bearer eyJhbGciOi...
Accept: application/json, text/event-stream
Content-Type: application/json
Content-Length: 218

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
  "protocolVersion":"2025-06-18",
  "capabilities":{"sampling":{},"elicitation":{}},
  "clientInfo":{"name":"claude-code","version":"2.1.0"}}}

HTTP/1.1 200 OK
Content-Type: application/json
Mcp-Session-Id: 1d31a3f4-c1d4-4e9c-9e10-bd8c2c7d3001
Content-Length: 312

{"jsonrpc":"2.0","id":1,"result":{
  "protocolVersion":"2025-06-18",
  "capabilities":{"tools":{"listChanged":true}},
  "serverInfo":{"name":"acme-search","version":"3.4.0"}}}

POST /mcp HTTP/1.1
Mcp-Session-Id: 1d31a3f4-...
MCP-Protocol-Version: 2025-06-18
Content-Type: application/json
Accept: application/json, text/event-stream

{"jsonrpc":"2.0","method":"notifications/initialized"}

HTTP/1.1 202 Accepted
Content-Length: 0

POST /mcp HTTP/1.1
Mcp-Session-Id: 1d31a3f4-...
MCP-Protocol-Version: 2025-06-18

{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
  "name":"deep_search","arguments":{"q":"quark–gluon plasma","depth":3}}}

HTTP/1.1 200 OK
Content-Type: text/event-stream
Mcp-Session-Id: 1d31a3f4-...

event: message
id: 1
data: {"jsonrpc":"2.0","method":"notifications/progress",
       "params":{"progressToken":"x","progress":0.33,"total":1.0}}

event: message
id: 2
data: {"jsonrpc":"2.0","method":"notifications/progress",
       "params":{"progressToken":"x","progress":0.66}}

event: message
id: 3
data: {"jsonrpc":"2.0","id":2,"result":{
       "content":[{"type":"text","text":"42 sources..."}],
       "isError":false}}

GET /mcp HTTP/1.1
Mcp-Session-Id: 1d31a3f4-...
Accept: text/event-stream
Last-Event-ID: 0

HTTP/1.1 200 OK
Content-Type: text/event-stream

event: message
id: 17
data: {"jsonrpc":"2.0","method":"notifications/tools/list_changed"}

DELETE /mcp HTTP/1.1
Mcp-Session-Id: 1d31a3f4-...

HTTP/1.1 204 No Content

Wire Capture in 2026-07-28 — No Session at All 2026-07-28

The same client and server under 2026-07-28. Steps [1], [2] and [5] of the previous slide have no equivalent; [4] becomes a subscriptions/listen POST (slide 06b). What is left is one self-contained POST per call, plus what a legacy client sees if it tries the old shape.

POST /mcp HTTP/1.1
Host: search.example.com
Authorization: Bearer eyJhbGciOi...
Accept: application/json, text/event-stream
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
  "name":"search","arguments":{"q":"mcp"},
  "_meta":{"progressToken":"p1",
           "io.modelcontextprotocol/protocolVersion":"2026-07-28",
           "io.modelcontextprotocol/clientInfo":{"name":"example-host","version":"1.0.0"},
           "io.modelcontextprotocol/clientCapabilities":{}}}}

HTTP/1.1 200 OK
Content-Type: text/event-stream

data: {"jsonrpc":"2.0","method":"notifications/progress",
       "params":{"progressToken":"p1","progress":0.5}}

data: {"jsonrpc":"2.0","id":1,"result":{"resultType":"complete",
       "content":[{"type":"text","text":"42 sources..."}],"isError":false}}

GET /mcp HTTP/1.1                     → 405 Method Not Allowed
DELETE /mcp HTTP/1.1                  → 405 Method Not Allowed
POST /mcp  (initialize, no Mcp-Method header)
                                      → 400 Bad Request (required headers missing;
                                        SHOULD name the supported versions)
Mcp-Session-Id / Last-Event-ID headers → ignored

Source: MCP specification 2026-07-28 — Streamable HTTP: backward compatibility; Versioning: compatibility matrix; Progress (accessed 2026-10-08).

Choosing a Transport in 2026

Migrating off HTTP+SSE

If you ship an HTTP+SSE server today, the migration is incremental:

1. Keep the old POST /messages + GET /sse endpoints alive for one major version of your client.
2. Add the unified /mcp endpoint that speaks Streamable HTTP.
3. Advertise the new endpoint via your service-discovery channel (homepage, well-known, README).
4. Drop the old endpoints once usage falls below your retention threshold.