The MCP roadmap hands agent identity to your gateway

The Model Context Protocol published an updated roadmap on August 22, organised into five priority areas. Two of them — agent identity and the growing cost of a large tool list — describe problems that get solved in front of an MCP server rather than inside it. The protocol is getting narrower, and the capabilities it sheds land on infrastructure that most teams already run. That is not a promotion for gateways. It is the protocol declining to reinvent things HTTP solved, and the roadmap is explicit about where it is heading.

What already shipped in 2026-07-28

The roadmap’s own “looking back” section is the useful starting point, because the release it describes changed the deployment story more than the feature list.

The line worth quoting is the roadmap’s own summary of the transport work: with the 2026-07-28 release, a remote MCP server is “no different from any other HTTP workload, making it easy to host and operate one on any infrastructure.” The next step named is unification rather than expansion — stretching that one transport to cover more deployment modes, including local servers speaking Streamable HTTP over stdio.

Two headers, and what they give back

Mcp-Method: tools/call and Mcp-Name: search sit in the request head, with the JSON-RPC payload behind them. A tool call is legible to anything that reads headers.

POST /mcp HTTP/1.1
Host: tools.example.com
Mcp-Method: tools/call
Mcp-Name: search
Authorization: Bearer <token>
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search","arguments":{"q":"..."}}}

Cloudflare’s Matt Carey, quoted by InfoQ, spells out the consequence: a gateway, rate limiter or WAF can act per method and per tool using the same primitives it already applies to every other API. One commenter in that piece notes the spec goes further — tool arguments can be copied into headers for custom routing.

Read that as subtraction, not addition. Before, per-tool rate limiting meant a body-parsing proxy that understood JSON-RPC. Now it means a header match. The protocol did not gain a rate-limiting feature; it stopped hiding the information that existing rate limiters need.

Agent identity: the part that reaches your gateway

This is the priority area with the most immediate consequences, and the roadmap’s framing of the problem is precise. MCP authorization today “is built around a person approving access in a browser.” That works for interactive clients. But increasingly the callers are “agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents.” The stated goal is for servers to recognise and trust those identities “built on existing standards rather than pasted API keys and long-lived tokens.”

Four mechanisms are named. They solve different problems, and it is worth separating them:

The roadmap also commits to continued engagement with the IETF OAuth and WIMSE working groups — a signal that this is meant to converge with standards rather than fork from them.

For anyone running MCP servers behind a shared entry point, the practical reading is that credential shape is becoming the design question. We wrote about that shape from the agent’s side in エージェントに渡す鍵の形 — short-lived, scoped, capped — and the roadmap is the protocol-side version of the same argument.

At PiRouter we are designing our own key handling around exactly that: credentials that carry a scope and an expiry rather than long-lived secrets pasted into a config file. That is a description of the design, not a claim about what is shipping today.

Tool bloat is a routing problem wearing a costume

The primitives section contains the sentence that will be quoted most: “Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows.”

Two costs, one cause. Tokens are the visible one. Selection accuracy is the one that shows up as an agent picking the wrong tool and nobody noticing for a week.

The HN thread on the roadmap is full of teams that hit this already and built the obvious workaround. One describes 400+ endpoints behind a single server, tagged by category in the OpenAPI spec, with the MCP layer returning at most ten endpoints per request and paginating from there. Another makes the structural version of the argument: design specialised sub-agents that only ever see a subset of the catalog.

Both are catalog-shaping — deciding which slice of a tool surface a given caller sees. That is the same class of problem as deciding which model a request should reach: a catalog too large to put in front of the model every time, and a decision about which slice earns the context budget.

The overreach critique, taken seriously

Not everyone reads the direction as narrowing. Roman Agaev argues the opposite: that MCP is re-encoding infrastructure semantics inside a layer-7 application protocol, and that protocols win by being a narrow waist rather than a stack-in-a-box. He names three specifics. They do not all land the same way.

The test Agaev proposes — agent semantics or infrastructure plumbing? — is a good one, and by it the headers pass. A protocol that says “this request is a tools/call for search” is describing itself. A protocol that said “retry this twice with backoff” would be doing your service mesh’s job.

Worth noting where the roadmap agrees with him in practice: Tasks moved out of the core into an official extension, Enterprise-Managed Authorization is an extension, and SEP-2133 gives working groups an experimental-ext- path to try things without touching the specification. The extension surface is where the growth is being routed.

Three things to do this week

Nothing here requires waiting for the next specification release.

Read the headers you are already receiving. If MCP traffic passes through a gateway you control, Mcp-Method and Mcp-Name are on those requests now. Per-tool rate limits and per-method authorization are a config change, not a project.

Inventory your long-lived tokens. The agent identity work assumes you will want to stop pasting API keys well before the specification lands. Anywhere an agent holds a credential with no expiry and no scope is a place that work will eventually touch.

Count your tool surface. If a server exposes more than a few dozen tools to every caller, you are paying the catalog cost on every request today. Tag-based filtering and pagination are available now; the roadmap is describing a standard for what teams are already hand-rolling.

The 2026-07-28 release made MCP servers ordinary HTTP workloads. The roadmap reads like a plan to keep them that way — and ordinary HTTP workloads are exactly what the layer in front of them was built to handle.