# The MCP roadmap hands agent identity to your gateway

> Two of the five priority areas in the MCP roadmap published on August 22 — agent identity and tool-list bloat — land in front of the server, not inside it. DPoP, Workload Identity Federation, ID-JAG and token exchange each move work to the layer you already run. What the 2026-07-28 stateless release already gave that layer, and which parts of the overreach critique are correct.

- Published: Aug 22, 2026
- Author: PiRouter Team, Engineering
- Tags: mcp, gateway, agents
- Canonical: https://pirouter.ai/blog/mcp-roadmap-gateway

---
The Model Context Protocol published [an updated roadmap](https://blog.modelcontextprotocol.io/posts/mcp-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.

| Change | What it means for a server | What it means for the layer in front |
|---|---|---|
| Stateless core | No session store, no sticky routing | ✓ Any instance can serve any request — plain round-robin works |
| `Mcp-Method` / `Mcp-Name` headers | Required on Streamable HTTP requests | ✓ Method- and tool-level policy without parsing a body |
| Cacheable `tools/list` ([SEP-2549](https://blog.modelcontextprotocol.io/posts/2026-07-28/)) | Catalog responses carry cache metadata | ✓ A shared cache in front of N servers becomes possible |
| MRTR ([SEP-2322](https://blog.modelcontextprotocol.io/posts/2026-07-28/)) | Replaces server-initiated requests | ✓ Elicitation works without a long-lived connection |
| Enterprise-Managed Authorization | Available as an extension, now stable | ⚠ Stable, but an extension — the core does not carry it |

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.

```http
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](https://www.infoq.com/news/2026/08/mcp-stateless-gateway/),
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.

![Before-and-after comparison of an MCP request path: previously the gateway had to parse the JSON-RPC body and route stickily, now it matches on the Mcp-Method and Mcp-Name headers and any instance can serve](/blog/images/mcp-roadmap-gateway-headers.png "Fig. 1 — The same request, before and after 2026-07-28. What changed is not what the gateway can do, but how much it has to open to do it.")

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:

| Mechanism | Problem it addresses | Where the work lands |
|---|---|---|
| DPoP | A stolen bearer token is replayable anywhere | Client proves key possession; the verifying layer checks it |
| Workload Identity Federation | A cloud workload has no human to click "approve" | Trust an existing workload identity instead of issuing a key |
| ID-JAG grant | Enterprise wants central control over which agents reach which servers | Identity provider issues, gateway enforces |
| Standard token exchange | A sub-agent should get less authority than its parent | Exchange down-scoped tokens at delegation boundaries |

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 [エージェントに渡す鍵の形](/ja/blog/agent-credentials/) — 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](https://news.ycombinator.com/item?id=49399591) 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](https://www.linkedin.com/posts/romanagaev_ai-softwarearchitecture-mcp-activity-7481980451776294912-2MJq):
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 critique | Our read | Why |
|---|---|---|
| `ttlMs` / `cacheScope` duplicate HTTP `Cache-Control` | ✓ Agreed | Caching semantics are a solved layer. A second vocabulary means two places to be wrong, and the HTTP one already has proxies that honour it |
| `Mcp-Method` / `Mcp-Name` put routing in the protocol | ✗ Disagreed | These are not routing directives; they are metadata moved from an opaque body into a readable head. Routing stays entirely the gateway's decision — the protocol just stopped hiding the inputs |
| A bespoke error taxonomy duplicates problem-details | ⚠ Partly agreed | Protocol-level errors need protocol-level names, but anything that maps cleanly onto RFC 9457 should say so explicitly rather than invent a parallel code |

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.

---

## Sources

### blog.modelcontextprotocol.io

- [an updated roadmap](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/)
- [SEP-2549](https://blog.modelcontextprotocol.io/posts/2026-07-28/)

### infoq.com

- [quoted by InfoQ](https://www.infoq.com/news/2026/08/mcp-stateless-gateway/)

### news.ycombinator.com

- [HN thread](https://news.ycombinator.com/item?id=49399591)

### linkedin.com

- [argues the opposite](https://www.linkedin.com/posts/romanagaev_ai-softwarearchitecture-mcp-activity-7481980451776294912-2MJq)