Mcp-Method and Mcp-Name: routing MCP traffic without reading the body
MCP 2026-07-28 makes two HTTP headers mandatory that mirror the JSON-RPC call. What they unlock at the infrastructure layer, and the bypass you need to close.
This is the least dramatic change in the 2026-07-28 spec, and the highest return if you run the infrastructure.
Two headers become mandatory on the Streamable HTTP transport: Mcp-Method and Mcp-Name. They mirror the JSON-RPC method and the name being called in the request body. A request calling the export_all tool via tools/call now says so in its headers.
The problem this solves
Until now, every MCP request looked like the same request from the outside. Same URL, same HTTP method, same shape. The only way to know whether a call was a trivial read or a full database export was to open the JSON-RPC body.
That forced some unpleasant things. A gateway doing deep packet inspection to route. A blind WAF. Metrics that never got more granular than "MCP requests per second". A global rate limit that protects badly, because it treats listing tools and generating a report the same way.
With the two headers, all of that happens at the HTTP layer, with tools you already run.
What you can do the day you migrate
Per-tool rate limits. Ten calls a minute on your export tool, a thousand on search. Probably the most immediate win, and also the most effective abuse protection on a public MCP server.
Routing to dedicated pools. Expensive tools go to instances sized for them, without polluting the latency of fast calls.
WAF rules on writes. Filtering, alerting or step-up authentication on destructive tools only, without touching the rest.
Per-tool telemetry. Latency, error rate and volume per tool, straight from access logs. This is what lets you say after the migration whether anything degraded, and where.
Caching. List responses become identifiable without reading the body, so they can be cached at the edge.
Do this work during the migration, not after. You need a per-tool baseline before the switch in order to compare.
The security trap
These headers are declarative. They are supplied by the client, and nothing in the transport guarantees they match the body.
The attack is direct: send a request whose Mcp-Name identifies a harmless read-only tool while the JSON-RPC body calls a restricted one. If your authorization or rate limiting trusts the header without checking, you have built a clean, quiet bypass.
The rule is simple: the edge may use the headers to route, measure and throttle, but authorization is decided on the request body, server-side. And the server must explicitly reject any mismatch between header and body.
That rejection belongs in your security telemetry, not just your error logs. A header/body mismatch is almost never a client bug. It is a signal.
It is also one of the checks I run on every audit, because most hastily migrated servers validate one or the other, never both.
What to check on your side
- Does your server require both headers, or treat them as optional?
- Does it reject a request whose header does not match the body?
- Is that rejection counted and alerted on?
- Do your edge rules make an authorization decision, or only a routing one?
- Do your in-house clients send both headers correctly?
That last one breaks first. An internal client written a year ago that builds requests by hand rather than through the SDK will be rejected as soon as your server enforces the headers.
FAQ
Can I route on Mcp-Method alone?
Yes for coarse routing, between listings and tool calls. For per-tool rate limiting or routing you need Mcp-Name.
What do I do with a request that has no headers?
It depends on your compatibility strategy. If you still serve the older revision, the request probably comes from an older client and should be treated as such. If you only serve the new revision, reject it.
Does this replace authentication?
No, and that is the whole point of the previous section. These headers are an operational convenience, not a security mechanism.
Your edge may be trusting a declarative header
That is one of the audit checks. Send me your server and your gateway configuration, and within 24 business hours you get a breakdown of what is verified and what is not.
Ready to check? Get my MCP server audited →
Related reading
Got an MCP server to audit?
Five minutes to describe it. I reply within one business day with a first written diagnosis, free of charge.
Get my MCP server audited