If you build retrieval systems, the most consequential recent protocol change isn't about documents. It's about tools — and it's the same problem wearing a different hat.
MCP's lead maintainers, David Soria Parra and Den Delimarsky, published an updated roadmap on August 22, 2026, naming five priority areas: agentic messaging primitives, HTTP-native transport unification, agent identity and enterprise security, improved primitives, and SDK developer experience. The one that should matter most to retrieval teams is buried in "improved primitives."
Tool selection is ranking, and it degrades with corpus size
The maintainers state the problem without euphemism: 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. They're starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows.
That is a retrieval architecture decision expressed as a protocol change. Progressive discovery means the tool catalog stops being a flat manifest stuffed into the system prompt and becomes something you query — with an entry point, a narrowing step, and an implicit relevance function. Everyone shipping a large internal MCP surface has already built a private version of this: a router tool, a semantic index over tool descriptions, a hand-tuned namespace hierarchy. Standardizing it means the ranking quality question moves from your prompt-engineering backlog into the protocol's contract, and the failure modes become familiar ones — recall misses on the narrowing step, stale catalogs, descriptions written for humans rather than for embedding.
The July spec is the enabling layer
None of this is free-standing. The 2026-07-28 release removed the initialization handshake and protocol-level session state (SEP-2575, SEP-2567), so MCP servers can scale horizontally like any stateless HTTP service — no sticky sessions, no session affinity at the load balancer. Clients can call server/discover to learn a server's supported versions and capabilities up front, and list results are now cacheable (SEP-2549).
Cacheable list results with a TTL are the unglamorous precondition for progressive discovery: if the catalog is a queryable index, clients need to know when their slice of it is stale. The same release also makes multi-server deployments behind a load balancer practical, since a client no longer has to stay pinned to one server.
What to actually do
Two caveats. The roadmap doesn't announce availability — some foundations shipped in 2026-07-28, while other parts are extensions, open design work, or IETF drafts , and the agent identity track in particular remains largely draft. Tool result formats are still ambiguous: a tools/call response can express the same output in multiple shapes, and servers have no way to know which shape a client will show the model.
If you run an MCP surface: migrate off sessions first, then start treating tool descriptions as a retrieval corpus — measure selection accuracy at 10, 50, and 200 tools before the protocol makes that number your problem.