In short, buried in the transport section of the MCP 2026-07-28 release candidate are three changes that matter more to infrastructure teams than to anyone else: mandatory Mcp-Method and Mcp-Name headers, cache-control-style ttlMs and cacheScope fields, and standardized W3C Trace Context propagation. Together with the stateless core, they turn MCP from a protocol that gateways had to fight into one that meets them halfway. What the headers still don’t carry: who the caller is, whether the call should be allowed, and any record that it happened.
Everyone is writing about MCP going stateless, and the coverage is deserved. No handshake, no session ID, any request can hit any server replica, round-robin load balancing just works. If you want the deep dive on what that does to protocol state, my colleague Peter is writing one.
I want to talk about the part of the release candidate that made me sit up, because I spend my days around a gateway that authorizes agent traffic. It’s three transport changes, a few paragraphs in the announcement, and it fixes a problem every MCP-aware proxy has been engineering around since Streamable HTTP shipped in the 2025-03-26 revision.
The problem: MCP was opaque at the network layer
To an HTTP intermediary, MCP traffic used to look like nothing. Every operation, whether it listed tools, read a resource, or transferred money, arrived as a POST to the same endpoint. The thing that actually mattered, the JSON-RPC method and the tool being called, sat inside the request body.
So any middlebox that wanted to treat a tools/list differently from a tools/call had one option: buffer the request, parse the JSON-RPC envelope, and make its decision from the body. That works, and it’s what serious MCP gateways do today. But it puts body parsing on the hot path for every request, including the vast majority where a cheaper answer would have sufficed. Rate-limiters, load balancers, and WAFs that can’t parse JSON-RPC at all were simply blind. Layer 7 infrastructure spent thirty years learning to route on methods and paths, and MCP hid both.
Mcp-Method and Mcp-Name: Routing without body inspection
SEP-2243 fixes this at the obvious place. The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers: Mcp-Method carries the JSON-RPC method (tools/call, resources/read, and so on), and Mcp-Name carries the operation target, such as the tool name. The announcement states the goal plainly: load balancers, gateways, and rate-limiters can route on the operation without inspecting the body.
What this unlocks, roughly in order of how quickly teams will use it:
- Per-tool rate limiting. Throttle
tools/callfor an expensive tool without touching the cheap ones, in a stock rate-limiter that only reads headers. - Operation-aware routing. Send
resources/readto read-optimized replicas, or split list-type traffic from call-type traffic entirely. - Cheap early denies. A policy gateway can reject a request for a tool that no policy could ever allow before parsing a byte of body.
- Visibility in existing tooling. Access logs, metrics dashboards, and anomaly detection keyed on headers now see MCP operations instead of an undifferentiated stream of POSTs.
One design detail deserves attention: servers must reject requests where the headers and the body disagree. That’s what makes the headers usable for real decisions rather than hints. A client can’t advertise tools/list in the header and smuggle a tools/call in the body, because the terminating server will refuse it.
Still, if your gateway makes security decisions, the right way to hold this is defense in depth. The header is a claim the server will eventually verify; the body remains the truth. Fast-deny on headers is always safe, since a mismatch would have been rejected anyway. For the allow path on sensitive operations, an enforcement point should keep parsing the body, both because arguments matter (more on that below) and because “the server behind me validates the invariant my security decision depends on” is a sentence that should make any security engineer reach for their own validation.
ttlMs and cacheScope: Caching with permission
SEP-2549 gives list results and resource reads two new fields modeled on HTTP Cache-Control: ttlMs says how long the response stays fresh, and cacheScope says whether it may be shared across users.
Gateways have wanted to cache tools/list forever. Tool catalogs change rarely, agents ask for them constantly, and every wasted round trip adds latency to an agent loop that’s already slow. But caching without server guidance meant guessing, and guessing wrong across users is how one tenant sees another tenant’s tool catalog. cacheScope makes the safety question explicit, and puts the answer where it belongs: with the server that knows whether the response was personalized.
If you run a shared MCP gateway in front of internal servers, this is the difference between “we cache nothing because we can’t prove it’s safe” and an actual caching policy.
Trace context: The audit trail gets standard rails
SEP-414 documents W3C Trace Context propagation in _meta, fixing the key names for traceparent, tracestate, and baggage. Every SDK and every gateway now agrees on where trace identity lives in an MCP request.
This one reads like an observability footnote and is quietly the most important of the three for anyone who cares about accountability. Distributed tracing across agent systems mostly worked if you controlled every hop and configured every SDK the same way. The moment traffic crossed a boundary, a different SDK, a vendor’s server, someone else’s gateway, correlation broke, and your trace of “which agent triggered this tool call” ended mid-sentence.
With the key names fixed in the spec, a trace can survive the full path: agent to gateway to MCP server and back, across implementations, into any OpenTelemetry-compatible backend. For incident response, that’s the difference between “a tool call failed somewhere” and a single trace showing the agent, the gateway’s authorization decision, and the server’s execution as one causal chain. We’ve written before about why multi-hop correlation is where existing tools fall down; the spec just removed the excuse at the protocol layer.
And because the protocol is now stateless, all of this composes. A gateway no longer needs session affinity to keep a conversation coherent, so any proxy replica can handle any request, with the operation in the headers and the trace context in _meta. The 2026-07-28 revision is the first one that reads like its authors had a load balancer diagram on the wall.
What the headers still don’t carry
Here’s the boundary, and it’s the same boundary the auth-hardening post ended on. The new transport tells you what is being asked. It does not tell you three other things.
Who is asking. Mcp-Method: tools/call plus Mcp-Name: transfer_funds identifies the operation, not the caller. Agent identity has to come from somewhere outside the protocol: mTLS workload identity, a verified token, something the platform issued rather than the process claimed.
Whether it should be allowed. Headers make policy enforcement cheaper; they don’t supply the policy. “May the finance team’s reporting agent call transfer_funds with this amount” needs an engine evaluating rules against agent attributes and, for the cases that matter, the arguments in the body. The headers get you to the decision point faster. The decision is still yours.
What happened. A cacheable, traceable, header-routed request that no one records is still unaccountable. Trace context gives audit trails standard rails to run on, but something has to actually write the trail, and it can’t be the agent.
Read those three again. They are the accountability questions, and the transport section answers none of them, correctly, because a transport shouldn’t. But it is exactly the seam where an agent gateway earns its place. Lynx’s gateway sits on this seam today: every request authorized individually against Cedar policy under a SPIFFE workload identity, with the decision recorded in Agent Trail. The new headers make that architecture cheaper to run and easier to integrate, because the proxy can classify traffic before it parses it, and the trace that leaves the gateway now correlates with everything upstream and downstream by default. Protocol changes rarely hand an enforcement plane this much for free.
If you run infrastructure in front of MCP, do this
- Update any body-parsing routing or rate-limiting logic to read
Mcp-MethodandMcp-Namefirst, and keep body validation on the security-sensitive allow path. - Audit your caching layer against
cacheScopesemantics before enabling cross-user caching of list results. The field tells you when sharing is safe; honor it. - Wire
traceparentpropagation through your proxy now, while the SDKs are shipping support inside the ten-week validation window. Correlation only works if every hop plays. - Test against the release candidate before July 28. Servers rejecting header/body mismatches is a new failure mode your clients need to handle.
Key takeaways
- SEP-2243 puts the MCP operation in HTTP headers, so gateways, load balancers, and rate-limiters can act on MCP traffic without parsing JSON-RPC bodies. Servers enforce header/body agreement.
- SEP-2549 adds
ttlMsandcacheScope, making response caching a documented contract instead of a guess, including whether cross-user sharing is safe. - SEP-414 standardizes W3C Trace Context in
_meta, so traces survive multi-hop, multi-implementation agent systems end to end. - The transport now tells intermediaries what is being asked. Identity, authorization, and audit remain the gateway’s job, and the protocol just made that job considerably cheaper to do well.
The headers tell you what is being asked. Your gateway decides whether it’s allowed. Your audit trail proves what happened. The spec just handed you the first one for free; the other two are still yours to build, and they were always the hard part.
Lynx is Tigera’s security and governance platform for AI agents on Kubernetes: identity, policy, detection, and audit for every agent in your cluster. Read How Lynx Works or request early access at tigera.io/demo/.
Identity, authorization, and audit are the part the transport leaves to you — and the part that’s hardest to get right. Our whitepaper, Securing AI Agents on Kubernetes using Tigera Lynx, walks through how to build all three. Read the whitepaper →
