Streamable HTTP transport

What it is

The Model Context Protocol defines two standard transports. stdio carries messages over a local process's standard input and output. Streamable HTTP carries them over HTTP to a single URL, the MCP endpoint, such as https://example.com/mcp. It was introduced in protocol version 2025-03-26 and replaced the earlier HTTP+SSE transport, which is now deprecated.

Why it matters

It is what makes a remote MCP server possible. Because it is ordinary HTTP, it works through load balancers, proxies and firewalls, it can use standard authentication, and a server can scale across many instances.

How it works

In every revision, the client sends each message as its own POST with an Accept header listing application/json and text/event-stream. For a request, the server answers with one JSON object or opens an SSE stream that carries progress and ends with the response.

The revisions differ in the details:

• 2025-03-26 to 2025-11-25. A server may assign a session with the MCP-Session-Id header. A client may open a standalone SSE stream with GET for server-initiated messages, and streams can resume with Last-Event-ID. After initialisation the client sends MCP-Protocol-Version on every request.
• 2026-07-28. The GET stream and protocol-level sessions are gone. Every request carries its protocol version and capabilities in the body, mirrored into headers such as MCP-Protocol-Version, Mcp-Method and Mcp-Name so gateways can route without parsing the body; the server must reject a header that disagrees with the body. Long-lived notifications use a subscriptions/listen request.

In both, servers must validate the Origin header to stop DNS rebinding, and should authenticate every connection.

Example

POST /mcp HTTP/1.1
Authorization: Bearer <token>
Accept: application/json, text/event-stream
Content-Type: application/json
MCP-Protocol-Version: 2025-11-25

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"check","arguments":{"action":"..."}}}

Common pitfalls

• Buffering proxies. A reverse proxy that buffers responses holds SSE events back. The 2026-07-28 text says servers should send X-Accel-Buffering: no on SSE responses.
• Sessions as identity. A session ID must never stand in for authentication.
• Mixing eras. A client that speaks only 2026-07-28 and a server that speaks only 2025-11-25 must detect each other; the specification describes the fallback.

How actionlake handles it

The actionlake endpoint, https://connect.actionlake.com/mcp, speaks Streamable HTTP on every current revision: 2026-07-28, where each request carries its own version and server/discover lists what the server speaks, and the handshake revisions 2025-11-25, 2025-06-18 and 2025-03-26 (the last with JSON-RPC batching). It is POST-only and holds no session, so any instance can answer any request; it offers no GET stream and answers GET or DELETE with 405 and Allow: POST, which is the specification's answer for a server without one. Browser-sent Origin headers are checked against an allow-list. Each request is authenticated on its own; see OAuth for MCP. The API reference documents the REST twin of the same eight tools.