Buried in the 2026-07-28 MCP release candidate is a small change with outsized operational impact: every Streamable HTTP request must now carry two headers — Mcp-Method and Mcp-Name (SEP-2243). It looks like a footnote, but it's the piece that lets MCP run behind ordinary infrastructure. Here's what they do and how to adopt them cleanly.
The problem they solve
Before this change, an MCP request's intent lived entirely inside the JSON-RPC body. A tools/call for a dangerous write operation and a harmless tools/list looked identical to anything sitting in front of the server — a load balancer, an API gateway, a rate-limiter, a WAF. To route, throttle or audit by operation, that intermediary had to crack open and parse the body of every request, which is expensive, fragile and a layering violation. In a stateless world where servers sit behind plain round-robin balancers, that's exactly the bottleneck you want gone.
What the headers carry
Mcp-Method names the JSON-RPC method for the request — tools/call, tools/list, resources/read and so on. Mcp-Name names the specific target: the tool or resource the request acts on. Together they expose the request's intent at the HTTP layer, where gateways already operate. A rate-limiter can now cap tools/call to an expensive tool without touching reads. A gateway can route resources/read to a cache tier and writes to a primary. An audit log can record what was invoked without buffering and re-parsing bodies. It's the same idea that made REST verbs and paths routable — applied to MCP.
The catch: headers and body must agree
The headers aren't a free-text hint. Servers must reject requests where Mcp-Method/Mcp-Name disagree with the body, because a mismatch is either a bug or an attack — a request that advertises a benign tools/list to the gateway while smuggling a privileged tools/call past it. Treat the two as a single signed-together unit: whatever your client puts in the body, set the headers to match exactly, and have the server validate the pair on the way in. This is a genuine security boundary, not just an optimisation.
Adopting it without breakage
If you're on a current SDK, this is mostly handled for you — the transport layer sets and validates the headers, and your job is to stay on a supported major version. Hand-rolled clients and proxies need the most care: any middlebox that forwards MCP traffic must preserve these headers untouched, and any client must populate them. A header stripped by an over-eager proxy will surface as rejected requests that look a lot like the connection-closed errors people already chase. Pair this with the broader stateless migration and the SSE-to-Streamable-HTTP move, since they all land together in the same release.
Where it fits
These headers are one leg of the 2026 stateless story; the other is cacheable results and OAuth hardening — see the full 2026-07-28 spec rundown. If you operate servers at scale, the routing they unlock is what makes an enterprise MCP gateway and private MCP hosting practical. Browse more in the developer-tools category.