MCP Was Built for a Human at a Laptop. The 2026 Roadmap Is the Work of Taking Them Out

Four assumptions, four replacementsHover to explore

The Model Context Protocol roadmap was updated on 22 August 2026, and buried in the third priority area is the most clarifying sentence anyone has written about agent infrastructure this year:

Read the other four priority areas after that one and they stop looking like a feature list. They are one project with five fronts: the protocol was designed for a person sitting at a laptop, and production keeps discovering that nobody is there.

That reframe is worth an afternoon of your attention, because every item on the roadmap is something you are currently solving by hand — usually badly, usually without having noticed you made a decision.

1. The five priority areas, and what they actually are

The roadmap is explicit that this is a prioritisation document, not a release plan: SEPs — Specification Enhancement Proposals — that fall inside these areas "get expedited review and have the best chance of acceptance." Everything else waits.

The first four are architecture. The fifth is about how the other four reach you, which matters more than it sounds — it is the difference between a spec change landing in your SDK in weeks and landing in months.

2. The part that already shipped, and may already affect you

Before the roadmap, there was a release. The 2026-07-28 specification made the protocol core stateless, and that is the change most likely to touch a system you are running today.

Specifically, it removed the initialize/initialized handshake and the Mcp-Session-Id header. Each request now carries its own protocol version, client identity and capabilities in _meta. The consequence, in the spec's own framing, is that any request can land on any server instance behind a plain round-robin load balancer without shared storage.

Three other things landed in the same release that are easy to miss and immediately useful:

3. Progressive discovery is a cost story before it is an architecture story

Of everything on the roadmap, this is the one founders feel first, and the one most likely to be misfiled as a nicety.

The roadmap's framing is that servers "need more options to guide clients through large sets of tools," and that clients should "learn a server's tools and resources as they need them instead of ingesting the full catalog up front."

Here is why that is a line item on your invoice. Today, the tool catalog goes into the context window at the start of the session. Every tool. Every description. Every parameter schema. On every task. Connect four or five MCP servers of any substance and you are spending thousands of tokens before the model has read the user's first sentence — and paying it again on the next task, and the one after.

Two things follow. Until progressive discovery exists, the number of MCP servers you attach is a live cost decision, not a capability decision, and the right default is fewer servers with narrower tool sets. And when it does exist, the servers that benefit are the ones whose tools were organised into something a client could traverse — which is a design choice you can make now, in how you group and name tools, before any mechanism ships.

The roadmap also notes that progressive discovery has a "defined interaction with the caching work" — meaning discovery and TTL-based caching are being designed to work together rather than colliding. That is the sort of detail that decides whether a feature is usable in year one or year three.

4. Agent identity: the pasted API key is now a roadmap item

The third priority area is the one that names the problem out loud. The roadmap's own description of the current state:

Existing MCP servers lean on pasted API keys and long-lived refresh tokens.

That is an accurate description of nearly every agent system in production right now, including plenty that would describe themselves as secure. The work being prioritised against it:

The delegation half deserves emphasis, because it is the one that maps to a real architectural mistake. When an agent spawns a sub-agent today, the sub-agent almost always runs with the parent's credentials, because narrowing them requires machinery nobody built. That means the blast radius of the least trustworthy step in your chain is the blast radius of the whole chain. That is the mechanism, not a hypothetical — and it is the same conclusion we reached from the other direction in AI Agents Need Permission Systems, Not Better Prompts.

One caution, and it is the same one that applies to the protocol consolidation we covered last week: identity answers who is calling. It does not answer whether what they are asking for is a good idea. A perfectly authenticated agent that has read a malicious instruction from a web page will make its malicious call with impeccable credentials. Everything in the agent security guide about treating model-visible content as untrusted survives all of this unchanged.

5. How to read a roadmap when you are shipping in eight weeks

A roadmap is not a delivery date. The document says so itself — "current thinking rather than firm commitments," with a six-to-twelve-month horizon. Working groups are still forming for two of the five areas.

So the useful question is not "what should I wait for." It is "what does this tell me about where the seams should go."

The middle card is the one that carries the weight. Every item in the first four priority areas is something a team shipping today solves informally. The roadmap's value to a founder is that it tells you which of your informal solutions are temporary by design — and those are exactly the ones that deserve an interface rather than being spread across the codebase.

Concretely, for a team building an agent product this quarter: if your credential handling, your long-task handling, and your tool-catalog assembly each live in one place with a small surface area, you will adopt the standards when they land in your SDK and it will be unremarkable. If they are smeared through the call sites, you will not adopt them at all, and you will describe that as a prioritisation decision.

6. What the roadmap does not fix

Three things worth stating plainly, because a well-written roadmap creates a mild illusion of coverage.

It does not make agents reliable. Every item here is transport, identity, and discovery. None of it touches whether the model chose the right tool, read the result correctly, or should have stopped. That remains an evaluation problem and it remains yours.

It does not shorten your dependency chain. A stateless core and a unified transport make it easier to attach more servers. Easy is not free — each attached server is context cost, a failure mode, and a trust boundary. The protocol getting better at connections is not an argument for more connections.

It does not arrive on a schedule you can plan against. Two working groups are still forming. Tasks are still an extension working toward "eventual inclusion of the extension in the core protocol." Sensible planning treats every roadmap item as a thing that might land in your SDK next year, and builds as though it might not.

The honest summary

The MCP roadmap updated on 22 August is a better strategy document than most companies write about themselves, because it names its own wrong assumption in plain language instead of describing the fix as an innovation. The protocol was built for a person with a browser, on a laptop, waiting a couple of seconds for an answer from a handful of tools. Every one of those four clauses is now false in production, and the roadmap is the work of unwinding them.

For a founder, the practical content is not the feature list. It is the confirmation that four of the things you are currently hacking around — credentials for absent users, work that outlives a request, catalogs too big to load, and a transport that behaves differently on a laptop than in a cluster — are known-temporary, being worked on by named people, and worth putting behind an interface today.

Build the crude version. Keep the seam. Delete the workarounds that already have a standard.

Sources: Model Context Protocol — Roadmap, last updated 2026-08-22 · The 2026-07-28 Specification, MCP Blog · SEP-2575, Stateless MCP · SEP-2549, TTL for list results · SEP-2663, Tasks extension · Working and Interest Groups

Related Posts

A2A Just Moved In With MCP. Standardising How Agents Talk Is Not Standardising Whether They're RightAugust 20, 2026

Your AI Agent Has a Security Problem: A Founder's Security Guide for 2026July 17, 2026

Context Engineering: The Skill That Makes or Breaks AI MVPs in 2026April 2026