If you host a remote MCP server, the 2026-07-28 spec hands you an operations win that is easy to miss under the bigger stateless headline: MCP's routing surface moved out of the JSON body and into HTTP headers. Streamable HTTP requests now carry two new required headers, and the spec is explicit about why — "Your gateway, rate limiter, or WAF can route and meter on those headers instead of parsing JSON bodies."

The short version: commodity layer-7 infrastructure can now route, rate-limit, and block MCP traffic using plain header rules. No JSON-RPC parsing on the hot path. Combined with the same spec's move to stateless request/response, MCP finally behaves like ordinary HTTP to your edge.

The two headers#

Every Streamable HTTP request now advertises what it is doing before your app ever sees the body:

They duplicate what is inside the payload on purpose. Headers are the layer your gateway already speaks. A managed WAF that cannot (or will not) crack open a JSON-RPC body can match a header in one rule.

What you can now do at the edge#

Four jobs that used to force body inspection collapse into ordinary L7 config:

Route by capability. Send tools/call to your tool-execution fleet and resources/read to a read-optimized backend by matching Mcp-Method — no Lua, no body-parsing filter.

Rate-limit a single hot tool. If one tool is expensive, meter it by its Mcp-Name at the gateway. The noisy neighbor gets throttled before it touches your app.

Block a method at the WAF. Denying a method — say you never want a class of call from the public edge — is now a header deny rule, evaluated before the request reaches your process.

Cache the lists that never change. The spec pairs this with cacheable list results: tools/list, prompts/list, resources/list, and resources/read responses now carry ttlMs and cacheScope, so clients cache correctly instead of re-fetching a tool catalog that changes once a week.

The 2026-07-28 spec made MCP legible to infrastructure that only reads headers. That is what turns a bespoke protocol into something your existing edge already knows how to run.

Migrating your gateway rules#

The change is additive, so your move is to stop deep-inspecting bodies and start keying on the headers:

  1. Add header-based routes. Where a rule parsed the JSON body for the method, replace it with a match on Mcp-Method. Where it read a tool name from params, match Mcp-Name.
  2. Move rate limits to Mcp-Name. Per-tool budgets become per-header buckets — cheaper and easier to reason about than body-derived keys.
  3. Honor the cache fields downstream. If you run a caching layer for clients, respect ttlMs and cacheScope on list responses rather than hard-coding a TTL.
  4. Drop the sticky-session config. With the spec stateless, a plain round-robin balancer is enough — no shared session store to route around.

If you are working through the whole upgrade, this slots into the same pass as the rest of the 2026-07-28 migration checklist, and it pairs naturally with the routable-header confirmation prompts the spec introduced for multi round-trip requests. The header change is small, but it is the piece that lets you blue-green deploy an MCP server with the same boring, battle-tested edge you already run for the rest of your API — which, for a founder counting infra hours, is the whole point.