MCP's core maintainers, David Soria Parra and Den Delimarsky, published an updated roadmap on August 22 — five weeks after the 2026-07-28 specification, which they called the largest revision since the protocol launched. The roadmap names five priority areas: agentic messaging primitives, HTTP-native transport unification, agent identity and enterprise-ready security, improved primitives, and SDK developer experience. Two of those directly change how you build knowledge connectors.
Progressive discovery is retrieval over your own tool catalog
The maintainers state the problem plainly: connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked anything, and tool selection quality degrades as the list grows. The proposed answer is progressive discovery — a server exposes a small entry point and reveals more tools as the conversation narrows.
If you build knowledge tooling, you have already hit this. A connector layer over Confluence, Jira, Slack, a data warehouse, and three internal APIs is not ten tools; it is a catalog. The failure mode isn't that the model can't call the right tool, it's that the right tool is buried in a flat list competing for attention with ninety siblings, and every request pays the token cost.
What progressive discovery implies architecturally is that tool selection becomes a ranked retrieval step with its own recall and precision characteristics — the same problem as document retrieval, with a much smaller corpus and much higher cost per false negative. Teams that already run a router in front of their tool set have been doing this informally; standardizing it means the entry-point design, not the tool count, becomes the thing you tune. It also means your tool descriptions are now retrieval documents. Write them accordingly.
The roadmap also flags result handling: a `tools/call` response can carry the same output in more than one form, and a server developer has no way to know which form a given client puts in front of the model. The fix is standardizing on one contract. For anyone shipping a retrieval server that returns both structured records and a rendered summary, that ambiguity is a live source of silent quality variance across clients.
Identity for callers that aren't people
The second thread matters more for enterprise deployments. MCP authorization today assumes a human approving access in a browser. That model breaks when the caller is an autonomous cloud workload acting for an absent user, or delegating to sub-agents. The roadmap targets Demonstrating Proof of Possession, Workload Identity Federation, and standard token exchange — existing standards rather than long-lived API keys — with continued engagement with the IETF OAuth and WIMSE working groups.
Permission-aware retrieval over an internal knowledge base needs exactly this. If the agent can't carry a verifiable, scoped, delegable identity, your ACL filtering is service-account trust with extra steps.
Caveat worth holding: this is a backlog, not a shipped spec. Some foundations landed in 2026-07-28; the rest are extensions, open design work, and drafts.