The New MCP Roadmap  🔗 **Source:** [The New MCP Roadmap](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/) > [!note]+ Document Notes > tags: [model-context-protocol, agent-identity, protocol-design, tool-discovery, oauth-delegation, sdk-ergonomics] > author: MCP Core Maintainers > source: Model Context Protocol blog (blog.modelcontextprotocol.io) > reference: https://blog.modelcontextprotocol.io/posts/mcp-roadmap/ > date created: 2026-08-24 09:00 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: The New MCP Roadmap > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [MCP specification](https://modelcontextprotocol.io/) — the protocol this roadmap governs - SEP-2663 — the Tasks extension being matured into the specification - SEP-2133 — allows any Working or Interest Group to experiment in an `experimental-ext-` repository before a formal SEP - [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) — Demonstrating Proof of Possession, being finalised and driven to adoption - [IETF OAuth Working Group](https://datatracker.ietf.org/wg/oauth/about/) and WIMSE — the standards bodies MCP is engaging - Workload Identity Federation and the ID-JAG grant behind Enterprise-Managed Authorization — the delegation path being defined ## 📝 Summary - **What happened.** The MCP Core Maintainers published an updated roadmap covering the next specification release and beyond, developed with community maintainers and Working Groups. It organises protocol work into **five priority areas**, each owned by named Core Maintainers and one or more Working Groups. - **Why it matters.** Two of the five address problems anyone using MCP at any scale has hit. **Progressive discovery** targets the fact that 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." And **agent identity** addresses the mismatch between MCP's browser-consent authorization model and the reality that callers are increasingly cloud workloads acting for an absent user, or sub-agents receiving delegated authority. - **Key stakeholders.** MCP server and client developers; enterprises blocked on authorization that doesn't fit agents; SDK users, especially the growing group who build MCP integrations by pointing an agent at the libraries; anyone with a Specification Enhancement Proposal outside the five areas. - **Risks and tradeoffs.** The roadmap doubles as a **prioritisation notice with real consequences** — proposals outside the priority areas "aren't rejected automatically, but maintainer review time is scarce and goes to the roadmap first." No dates appear anywhere, which is honest but leaves adopters unable to plan. And the security work depends on standards bodies moving at their own pace. - **Bottom line.** The through-line is **MCP converging on existing infrastructure rather than inventing parallel mechanisms** — one HTTP-native transport, OAuth-family standards for identity, one clear result contract instead of several. The most consequential single item for practitioners is progressive discovery, because tool-surface bloat is the constraint people are hitting right now. The most consequential structurally is agent identity, because "pasted API keys and long-lived tokens" is what it is replacing. ## 📖 Main Content The framing is procedural and worth reading carefully: the roadmap "sets the direction for protocol work over the coming months," was developed by Core Maintainers **together with** community maintainers and Working Groups, and each of its five areas is **owned by named Core Maintainers and one or more Working Groups**. Several priorities are promotions — server-initiated events, result type improvements, and agent identity all appeared on the previous roadmap as "on the horizon" and "have since matured enough to become priorities in their own right." That is a functioning pipeline rather than a wish list, and the promotion history is evidence for it. **Agentic messaging primitives** starts from a correct observation: **"Modern agentic workloads no longer fit the standard request-and-response pattern."** Loops run longer, servers push streamed results, and there is a clear need to steer work mid-flight. MCP has already added Tasks, `subscriptions/listen`, and progress notifications — and the roadmap's stated concern is notable: not only offering the right primitives "but also that they work well together." A **composition review across the Agents, Transports, and Triggers & Events Working Groups** is explicitly part of the work. Protocols usually accrete primitives and discover the interaction problems later; scheduling a composition review before the primitives harden is unusual discipline. The concrete items are **server-initiated events** — webhooks and channels, "so clients aren't left polling for results" — and maturing the **Tasks extension (SEP-2663)** into the specification proper. **HTTP-native transport unification** reports an already-shipped result. With the **2026-07-28 release**, "a remote MCP server is now no different from any other HTTP workload, making it easy to host and operate one on any infrastructure that developers and organizations already use for their APIs and services." That is a significant operational claim: it means MCP servers inherit existing load balancers, observability, auth proxies, and deployment tooling rather than needing bespoke handling. The next step is stranger and more interesting: extending the same model to **local servers speaking Streamable HTTP over stdio**. Running an HTTP-shaped protocol over a pipe looks odd until you see the goal — **one transport** means client and server implementations stop branching on deployment mode. The stated rationale, "unifying on one transport lets us simplify MCP server and client development even further," is the kind of simplification that pays off in every SDK and every implementation simultaneously. **Agent identity and enterprise-ready security** contains the roadmap's sharpest problem statement. **"MCP authorization today is built around a person approving access in a browser."** That works for interactive clients and fails for three cases the roadmap names precisely: agents running as cloud workloads with their own identity; agents acting on behalf of a user who is not present; and agents delegating narrower authority to sub-agents. The third is the one most people have not thought about — sub-agent delegation with *reduced* scope is a genuine authorization primitive that currently has no expression. The stated goal is a standardised way for servers to recognise and trust agent identities **"built on existing standards rather than pasted API keys and long-lived tokens."** That last phrase is an accurate and slightly damning description of current practice. The work is specific and named: finalising **DPoP (Demonstrating Proof of Possession)** and driving adoption, and defining "an opinionated path" for agent identity and delegation through **Workload Identity Federation**, the **ID-JAG grant** behind Enterprise-Managed Authorization, and **standard token exchange**. Plus continued engagement with **IETF OAuth and WIMSE working groups** to help the underlying standards evolve with what agent identity needs. Two things stand out. **"Opinionated path"** is the right choice — a menu of standards-compliant options produces incompatible implementations, and someone has to pick. And engaging the standards bodies upstream rather than building around them is slower but avoids the outcome where MCP invents an identity mechanism the rest of the industry has to bridge to. **Improved primitives** contains the item most practitioners will feel first. The result-handling problem is stated crisply: **"A `tools/call` response can carry the same output in more than one form, and a server developer today has no way to know which form a given client will put in front of the model."** That is an interoperability bug wearing flexibility's clothing — the server cannot reason about what the model will actually see, which makes reliable tool authoring guesswork. The fix is standardising on one clear contract, which will break some implementations and is obviously correct anyway. The scale problem is the one worth quoting in full: **"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 distinct costs — tokens spent on definitions nobody needed, and *degraded selection accuracy* as the list grows. The second is the more damaging and the less obvious. The response is **progressive discovery**: "a server can offer a small entry point and reveal more of its catalog as the conversation narrows." Described as "starting an effort," so it is the least mature item. It is also the one that most directly determines whether MCP scales to servers with large tool surfaces, and the pattern is already being approximated by clients that defer tool schemas and load them on demand — so the protocol is following practice rather than leading it, which is usually the right order. **Improved SDK developer experience** ends with a genuinely modern observation. SDKs get investment in ergonomics, conformance with the specification, and documentation across every supported platform and language. The reason given: **"This is even more important now that many developers build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work with minimal friction."** That inverts the usual justification for documentation quality. Docs are no longer only for humans reading them — they are context an agent consumes, and their accuracy determines whether generated code works. Ambiguous docs used to cost a developer twenty minutes; now they produce plausible, wrong code at scale. This connects directly to the same batch's argument that agent effectiveness is bounded by the surfaces we give them, and it is unusual to see a protocol project state it as a design driver. **The prioritisation notice deserves separate attention** because it is the part with immediate consequences for contributors. SEPs within the five areas **"get expedited review and have the best chance of acceptance."** Proposals outside them "aren't rejected automatically, but maintainer review time is scarce and goes to the roadmap first." The advice is practical: identify the priority area your proposal belongs to, raise it with the relevant Working Group, and work with its members to shape it. This is an honest statement of a real constraint, and it is better than the common alternative of leaving proposals to age in a queue with no explanation. It also has an obvious cost: work that does not map to a priority area effectively stalls, and the areas were set by the maintainers. Participation routes are concrete: join a Working or Interest Group; propose or comment on a SEP; **start an experimental extension** — SEP-2133 lets any WG or IG experiment in an `experimental-ext-` repository before a formal SEP; or contribute directly to the specification, SDKs, and tooling. Each area names its responsible Core Maintainers, reachable on Discord. The experimental extension mechanism is the underrated governance item here. Letting groups build and try things in a designated space *before* formalising avoids the failure mode where a specification process only accepts fully-formed proposals, which selects for people with time to write specifications rather than people with working implementations. Two caveats. **No dates appear anywhere.** "The coming months" is the only temporal commitment, which is honest for a community-driven specification but leaves adopters unable to plan around, say, whether agent identity lands before their enterprise deployment. And the security work has a genuine external dependency: engagement with IETF working groups means MCP's timeline is partly not MCP's to set. ### 🗒️ Notes #### Framing and process - Updated roadmap covering the next specification release and beyond; "sets the direction for protocol work over the coming months." - Developed by **Core Maintainers together with community maintainers and Working Groups** — not handed down. - **Five priority areas**, each owned by named Core Maintainers and one or more Working Groups. - **Promotion history as evidence of a working pipeline:** server-initiated events, result type improvements, and agent identity were all "on the horizon" on the previous roadmap and "have since matured enough to become priorities in their own right." #### 1. Agentic messaging primitives - Correct problem statement: **"Modern agentic workloads no longer fit the standard request-and-response pattern."** Longer loops, servers pushing streamed results, need to steer work mid-flight. - Already shipped toward this: **Tasks**, **`subscriptions/listen`**, **progress notifications**. - **The unusual discipline:** the concern is not only having the right primitives "but also that they work well together" — with an explicit **composition review across the Agents, Transports, and Triggers & Events Working Groups**. Most protocols accrete primitives and find the interaction problems afterwards. - Concrete work: **server-initiated events** (webhooks and channels) "so clients aren't left polling for results"; maturing the **Tasks extension (SEP-2663)** into the specification. #### 2. HTTP-native transport unification and hardening - **Already shipped, in the 2026-07-28 release:** "a remote MCP server is now no different from any other HTTP workload, making it easy to host and operate one on any infrastructure that developers and organizations already use for their APIs and services." - Operationally significant — MCP servers inherit existing load balancers, observability, auth proxies, and deployment tooling instead of needing bespoke handling. - **Next, and initially odd-looking: local servers speaking Streamable HTTP over stdio.** HTTP over a pipe makes sense once the goal is visible — one transport means implementations stop branching on deployment mode. - Stated rationale: "unifying on one transport lets us simplify MCP server and client development even further." A simplification that pays off across every SDK simultaneously. #### 3. Agent identity and enterprise-ready security - **The sharpest problem statement in the roadmap:** "MCP authorization today is built around a person approving access in a browser." - Three failing cases, named precisely: agents running as **cloud workloads with their own identity**; agents acting **on behalf of a user who isn't present**; agents **delegating narrower authority to sub-agents**. - The third is the one most people haven't considered — **scope-reducing sub-agent delegation currently has no expression in the protocol.** - Goal: standardised recognition and trust of agent identities **"built on existing standards rather than pasted API keys and long-lived tokens"** — an accurate and slightly damning description of current practice. - Named work: finalising **DPoP** and driving adoption; an **"opinionated path"** for identity and delegation via **Workload Identity Federation**, the **ID-JAG grant** behind Enterprise-Managed Authorization, and **standard token exchange**. - **Upstream engagement:** continued work with **IETF OAuth and WIMSE** working groups so the underlying standards evolve with what agent identity needs. - Two good calls: "opinionated path" avoids incompatible standards-compliant implementations; engaging standards bodies avoids inventing a mechanism everyone else must bridge to. #### 4. Improved primitives — the practitioner-facing area - **Result handling:** "A `tools/call` response can carry the same output in more than one form, and a server developer today has no way to know which form a given client will put in front of the model." - That is an **interoperability bug wearing flexibility's clothing** — the server can't reason about what the model actually sees, so reliable tool authoring is guesswork. Fix: standardise on one clear contract. - **Scale, quoted in full:** "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 distinct costs:** tokens spent on unneeded definitions, and **degraded selection accuracy** as the list grows. The second is more damaging and less obvious. - Response: **progressive discovery** — "a server can offer a small entry point and reveal more of its catalog as the conversation narrows." - Described as "starting an effort," so least mature. Also the item that most determines whether MCP scales to large tool surfaces — and clients already approximate it by deferring tool schemas, so the protocol is following practice rather than leading it. #### 5. Improved SDK developer experience — with a modern justification - Investment in **ergonomics, conformance with the specification, and documentation** across every supported platform and language. - **The reason given is the notable part:** "This is even more important now that many developers build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work with minimal friction." - **Docs are now agent context, not just human reading material.** Ambiguous docs used to cost a developer twenty minutes; now they produce plausible, wrong code at scale. - Connects directly to this batch's recurring theme: agent effectiveness is bounded by the quality of surfaces we give them. Unusual to see a protocol project name it as a design driver. #### Proposal prioritisation — the part with teeth - SEPs within the five areas **"get expedited review and have the best chance of acceptance."** - Outside them: **"aren't rejected automatically, but maintainer review time is scarce and goes to the roadmap first."** - Practical advice: identify the priority area, raise it with the relevant Working Group, work with members to shape the proposal. - **Honest about a real constraint** — better than letting proposals age silently. **Obvious cost:** off-roadmap work stalls, and the maintainers set the roadmap. #### Getting involved - **Join a Working or Interest Group** — see the Working and Interest Groups page and community channels. - **Propose or comment on a SEP** — read the SEP guidelines first. - **Start an experimental extension: SEP-2133 lets any WG or IG experiment in an `experimental-ext-` repository before a formal SEP.** - **Contribute directly** to the specification, SDKs, and tooling. - Each area names its responsible Core Maintainers, reachable on **Discord**. - **The underrated governance item is SEP-2133.** Building before formalising avoids a process that only accepts fully-formed proposals — which otherwise selects for people with time to write specifications over people with working implementations. #### Two caveats - **No dates anywhere.** "The coming months" is the only temporal commitment. Honest for community-driven specification work; leaves adopters unable to plan around whether, say, agent identity lands before an enterprise deployment. - **External dependency on standards bodies.** IETF engagement means the security timeline is partly not MCP's to set. ## 📚 References - [Model Context Protocol](https://modelcontextprotocol.io/) — specification and documentation - [MCP specification repository](https://github.com/modelcontextprotocol) — SEPs, Working Groups, contribution guide - [RFC 9449 — DPoP](https://datatracker.ietf.org/doc/html/rfc9449) — proof-of-possession tokens - [IETF OAuth Working Group](https://datatracker.ietf.org/wg/oauth/about/) — where the underlying standards evolve - [IETF WIMSE Working Group](https://datatracker.ietf.org/wg/wimse/about/) — workload identity in multi-service environments - [OAuth 2.0 Token Exchange (RFC 8693)](https://datatracker.ietf.org/doc/html/rfc8693) — the delegation primitive referenced ## 🗣️ Paraphrase - **Purpose.** An updated protocol roadmap setting direction for the next specification release and the following months, produced collaboratively by core and community maintainers. - **Structure.** Five priority areas, each with named owners and associated working groups; several were previously listed as future possibilities and have matured into priorities. - **Messaging.** Agent workloads no longer fit request-and-response, so the protocol is adding longer-running and steerable interaction primitives, and reviewing whether they compose correctly. - **Events.** Servers will be able to initiate events so clients need not poll for results. - **Transport.** A recent release made remote servers behave like ordinary HTTP workloads, deployable on existing infrastructure; the next step extends that model to local servers so only one transport exists. - **Identity, problem.** Authorization currently assumes a person approving access in a browser, which fails for autonomous workloads, absent users, and delegation to sub-agents with reduced scope. - **Identity, approach.** Build on existing identity standards rather than shared keys and long-lived tokens, choosing an opinionated path through established federation, grant, and token exchange mechanisms. - **Identity, upstream.** Continue participating in the relevant standards bodies so the underlying specifications develop the pieces agent identity requires. - **Results.** Responses can currently express the same output several ways with no signal about which a client will show the model, so one contract will be standardised. - **Scale.** Large tool catalogues cost tokens before any question is asked and degrade selection accuracy, so servers will be able to reveal their catalogue progressively. - **SDKs.** Ergonomics, specification conformance, and documentation accuracy are being prioritised, particularly because integrations are increasingly generated by agents reading the libraries. - **Prioritisation.** Proposals aligned with the five areas receive faster review and greater likelihood of acceptance; others are not refused but compete for scarce attention. - **Participation.** Join a group, propose or comment on an enhancement, experiment in a designated pre-proposal repository, or contribute to specification, libraries, and tooling. ## 📰 Newsletter **The MCP roadmap has five priorities, and two of them are problems you've already hit** The Core Maintainers published an updated roadmap. Five priority areas, each with named owners and Working Groups. Worth reading if you build with MCP — and two items are things you've probably already worked around. **Progressive discovery.** Here's the problem, in their words: *"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 there, and the second is the one that bites. Tokens are the obvious one. **Selection accuracy degrading as the catalogue grows** is the one that quietly makes your integration worse without an obvious cause. The fix: servers offer a small entry point and reveal more as the conversation narrows. It's the least mature item on the list — "starting an effort" — and clients are already approximating it by deferring tool schemas until needed, so the protocol is following practice rather than leading. Usually the right order. **Agent identity.** The sharpest problem statement in the doc: *"MCP authorization today is built around a person approving access in a browser."* Fine for interactive clients. Useless for the three cases they name — agents as cloud workloads with their own identity, agents acting for an absent user, and agents **delegating narrower authority to sub-agents.** That third one is the one I hadn't thought hard about: scope-*reducing* delegation is a real authorization primitive with no current expression. They want this built on existing standards *"rather than pasted API keys and long-lived tokens"* — which is an accurate and slightly withering description of how most of us are doing it right now. The named work is DPoP, Workload Identity Federation, the ID-JAG grant, and standard token exchange, plus continued engagement with **IETF OAuth and WIMSE**. Two good calls: committing to an "opinionated path" (a menu of standards-compliant options just produces incompatible implementations) and going upstream rather than inventing something everyone has to bridge to later. **Already shipped, and easy to miss:** as of the 2026-07-28 release, *"a remote MCP server is now no different from any other HTTP workload."* Your existing load balancers, observability, auth proxies, and deploy tooling just work. Next they want local servers speaking **Streamable HTTP over stdio** — which sounds absurd until you realise the goal is *one transport*, so implementations stop branching on deployment mode. **The bit I keep thinking about** is buried in the SDK section: > many developers build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work with minimal friction Docs aren't just for humans anymore. They're **agent context**, and their accuracy determines whether generated code works. Ambiguous docs used to cost a developer twenty minutes. Now they produce plausible, wrong code at scale. It's unusual to see a protocol project name that as a design driver, and it lands right on the thread running through everything else this week — agent effectiveness is bounded by the quality of the surfaces we hand them. **If you're planning to propose something:** SEPs inside the five areas get expedited review and *"the best chance of acceptance."* Outside them, *"maintainer review time is scarce and goes to the roadmap first."* That's honest — better than letting proposals rot in a queue with no explanation — but it means off-roadmap work effectively stalls. The underrated escape hatch is **SEP-2133**, which lets any Working or Interest Group experiment in an `experimental-ext-` repo *before* writing a formal SEP. That's good governance: it stops the process selecting for people with time to write specifications over people with working code. **One caveat:** no dates anywhere. "The coming months" is the whole temporal commitment. Honest for community-driven spec work, unhelpful if you need to know whether agent identity lands before your enterprise rollout. And the security work partly depends on IETF timelines, which aren't MCP's to set. ## ✅ Action Items #### DevRel - Developer advocacy: build the explainer on the three agent identity cases — cloud workload, absent user, sub-agent delegation. Most people have only thought about the first. - Education: teach progressive discovery as a design pattern now, since clients are already approximating it and the protocol is codifying practice. - Developer experience: **treat documentation accuracy as agent infrastructure.** The roadmap makes this explicit and it applies to every library, not just MCP SDKs. - Developer marketing: "your MCP server is now just an HTTP workload" is the clearest adoption argument available and it has already shipped. - Community management: point contributors at SEP-2133 — experimenting before formalising lowers the barrier for people with implementations but no specification-writing time. - Internal/external/cross-project: the tool-surface bloat problem affects every agent platform, not just MCP. Worth coordinating rather than each solving it separately. #### OSPO - Policy & Governance: the prioritisation notice is a good model — publicly stating which work gets scarce review attention is fairer than silent queue aging. Consider adopting the pattern. - License Compliance: not applicable to this source. - Security Management: **audit where you currently use pasted API keys and long-lived tokens for MCP access.** That is the practice this work is replacing, and it is presumably widespread internally. - Software Inventory: track which MCP servers you run and how many tools each exposes — the token and selection-accuracy costs scale with that number. - Developer Support: prepare guidance for the result-contract standardisation, which will break implementations relying on current ambiguity. - Community Engagement: join the relevant Working Group if agent identity affects your deployment; the roadmap explicitly invites it and names the maintainers. - Strategic Alignment: agent identity and delegation is an enterprise blocker being actively worked; plan around it rather than building a bespoke workaround that will need unwinding. #### Community - Maintainers: if you run an MCP server with a large tool surface, progressive discovery will change how you structure your catalogue. Start thinking about entry points now. - Contributors: SEP-2133 experimental extensions are the lowest-barrier way in — build the thing, then propose it. - Sponsors: fund SDK documentation and conformance work. It is unglamorous and, per the roadmap's own reasoning, now determines whether generated integrations work at all. - Ecosystem: agree on progressive discovery conventions early; divergent approaches to catalogue revelation would be worse than the current bloat. #### WordPress - Core: not applicable to this source. - Core Performance: tool-surface token cost is a performance concern for any WordPress AI integration — every exposed ability is paid for on every request. - Core AI: **directly relevant.** The WordPress MCP's ability surface will hit the same hundred-tool problem; progressive discovery is the answer being standardised, and worth tracking rather than solving independently. - **Core Program Team:** the named-owner-per-area structure is a decent model for cross-team feature ownership. - Mobile: not applicable to this source. - Playground: not applicable to this source. - Community: not applicable to this source. - Training: teach the read-versus-write distinction in agent abilities alongside identity and delegation; it is the practical safety lever available today. - Marketing: not applicable to this source. - Support: not applicable to this source. - Design: not applicable to this source. - Documentation: **the roadmap's SDK reasoning applies to WordPress developer docs directly** — they are now consumed by agents generating plugin code, and inaccuracy scales into wrong code rather than one confused reader. - Photos: not applicable to this source. - TV: not applicable to this source. - Polyglots: not applicable to this source. - Accessibility: not applicable to this source. - Meta: if .org ever exposes MCP surfaces, agent identity and delegation is the design question to settle before shipping, not after. - CLI: WP-CLI and MCP overlap as agent surfaces; the identity model MCP is defining is worth borrowing rather than reinventing. - Hosting: MCP servers as ordinary HTTP workloads means hosts can support them with existing infrastructure — a low-cost differentiator. - Tide: not applicable to this source. - Openverse: not applicable to this source. - Themes: not applicable to this source. - Plugins: **plugins exposing MCP abilities inherit these problems** — result contract ambiguity today, tool-surface bloat as more plugins expose abilities. WooCommerce extending MCP across its extensions is exactly the pattern that will hit the hundred-tool wall. #### The WPOCC - Programs: a session on agent identity and delegation would serve the many WordPress professionals now wiring agents into client sites without a coherent auth model. - Projects: document the read-only-by-default posture as a community norm while the identity work matures — it is the available mitigation. - Funding experiments: not applicable to this source. ### FAIR - Technical independence: building identity on open standards (OAuth family, IETF working groups) rather than a proprietary mechanism is genuinely independence-preserving and worth noting approvingly. - Policies and covenants: scope-reducing delegation to sub-agents is a governance primitive as much as a technical one — it is how you bound what automation may do on your behalf. - Productized governance artifacts: the named-owner-per-priority-area structure, plus a public statement of what gets review attention, is a reusable governance pattern. ### 🧪 Hypotheses 1. **Tool selection accuracy degrades measurably with catalogue size.** Model tool-selection error rates will rise with the number of exposed tools, independent of tool quality — the roadmap asserts this and it is directly testable. 2. **Progressive discovery reduces token cost without reducing capability.** Servers exposing a small entry point will show materially lower per-session token consumption at equivalent task success rates versus full-catalogue exposure. 3. **Result contract ambiguity causes real interoperability failures.** A meaningful proportion of MCP server bugs will trace to the server assuming a different output form than the client presented to the model. 4. **Documentation accuracy predicts generated-integration success.** SDKs with higher documentation accuracy will produce working agent-generated integrations at a higher rate, controlling for API complexity. 5. **Transport unification reduces implementation size.** Client and server implementations after stdio-over-Streamable-HTTP unification will contain measurably less deployment-mode branching logic. 6. **Roadmap alignment predicts SEP acceptance.** Proposals within the five priority areas will show higher acceptance rates and shorter time-to-review than those outside — which is the stated policy, and worth verifying it operates as described. ### 📊 Methodology - **H1:** Controlled evaluation — same task set, same tools, catalogue size varied by padding with irrelevant tools. Measure selection accuracy against ground truth. Cheap, decisive, and the result would inform every agent platform. - **H2:** A/B progressive versus full exposure on a server with a large catalogue, measuring tokens per session and task completion. Requires progressive discovery to exist first, so this is a post-implementation evaluation. - **H3:** Classify MCP server issue trackers for bugs traceable to output-form mismatch. Public data across many servers; needs a coding scheme. - **H4:** Have agents generate integrations against SDKs of varying documentation quality, then measure first-run success. Documentation quality is the hard variable to operationalise — conformance test coverage may serve as a proxy. - **H5:** Straightforward before-and-after code analysis on the reference implementations, counting deployment-mode conditionals. - **H6:** Repository analysis of SEP outcomes segmented by roadmap alignment. Public, immediate, and it holds the maintainers to their own stated policy — which is the useful kind of accountability. ### ❓ Questions - What is the actual shape of progressive discovery — does the server decide what to reveal, or does the client request narrowing, and who holds the state? - Which result form wins in the standardised contract, and what breaks for servers relying on the current ambiguity? - How does scope-reducing sub-agent delegation get expressed and, more importantly, *enforced* — is the reduction advisory or verified? - Does "opinionated path" mean other standards-compliant approaches become non-conformant, or merely unsupported? - Without dates, how should an enterprise plan a deployment that needs agent identity? - What happens to a well-formed proposal that falls outside all five areas — is there any route other than waiting for the next roadmap? - Does HTTP-over-stdio introduce overhead that matters for local servers, and was that measured? - If tool selection degrades with catalogue size, is there a currently recommended maximum, and does anyone publish one? ### 🔮 Future Research - **Tool catalogue scaling.** The claim that selection degrades with list size is asserted across the industry and rarely measured. A clean study would inform protocol design well beyond MCP. - **Agent identity models.** Scope-reducing delegation to sub-agents is a genuinely novel authorization requirement; whether existing OAuth-family primitives express it adequately is an open question the IETF engagement will effectively answer. - **Documentation as agent context.** The roadmap states the premise; nobody has measured how documentation quality translates into generated-code correctness. - **Protocol composition.** Scheduling a composition review before primitives harden is unusual. Whether it prevents the interaction problems that plague mature protocols is worth following as a case study. - **Progressive disclosure patterns.** Multiple clients are independently approximating this. Comparing approaches before standardisation would inform the specification. - **Transport unification tradeoffs.** Running HTTP semantics over stdio has costs; whether simplification outweighs them at scale is measurable and unmeasured. ### 💡 Implications - **Practice.** If you run an MCP server, the number of tools you expose is a live cost — in tokens and in selection accuracy — before progressive discovery exists. Audit it now. If you consume MCP, expect the result contract to tighten. - **Policy.** The prioritisation notice is a governance pattern worth copying: publicly stating what gets scarce review attention is fairer than silent queue aging, even though it stalls off-roadmap work. - **Security.** "Pasted API keys and long-lived tokens" describes most current MCP deployments. That is the practice being replaced, and until it is, read-only-by-default is the available mitigation. - **Education.** The three agent identity cases — cloud workload, absent user, sub-agent delegation — are a good teaching frame, and the third is the one most practitioners have not considered. - **Funding.** SDK documentation and conformance work is now, by the maintainers' own reasoning, the thing that determines whether agent-generated integrations work. It is also the least fundable-sounding line item in the roadmap. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade Level ≈ 14; Flesch Reading Ease ≈ 32. Dense specification-adjacent prose with heavy noun phrases and acronym stacking. Comprehension requires prior knowledge of MCP concepts, OAuth, and the SEP process; the writing is precise rather than accessible, which is appropriate for the audience. #### 👀 Visual learners - Present: one diagram naming the five priority areas, which conveys the structure at a glance. - Improve: no diagram of the identity and delegation flow, which is the most conceptually demanding item and the one that would benefit most. A sub-agent delegation sequence diagram would do real work. #### 🔊 Aural learners - Present: none; text-only announcement. - Improve: **Not applicable to this source** — a specification roadmap with no audio dimension. #### 🗣️ Verbal learners - Present: strong. Problems are stated in plain language before solutions are named — the hundred-tools sentence and the browser-consent sentence are both models of concise problem statement. - Improve: heavy unexplained acronym load — DPoP, ID-JAG, WIMSE, SEP, WG, IG — in a document that will be read by people evaluating whether to adopt MCP. #### 🧩 Kinesthetic learners - Present: excellent participation routes — join a group, propose or comment on a SEP, start an experimental extension, contribute to specification or SDKs. - Improve: no example of what an `experimental-ext-` repository looks like in practice, which is the most inviting route and the least documented here. #### 🧠 Logical learners - Present: consistent structure throughout — problem, why current approach fails, named work items, owning group. Priorities are justified by their promotion history rather than asserted. - Improve: no sequencing or dependency information. Several items plainly depend on others (result contract before progressive discovery, arguably), and none of that is stated. #### 🧑‍🤝‍🧑 Social learners - Present: heavily community-oriented — Working Groups, Interest Groups, Discord, named maintainers per area, explicit invitation to shape proposals with group members. - Improve: no indication of group activity levels or how to judge which needs contributors most. #### 🧘‍♀️ Solitary learners - Present: self-contained and linked out to the full roadmap, SEP guidelines, and contributing guide. - Improve: no summary of what changed since the previous roadmap beyond the promotion note, so a returning reader must reconstruct the delta. #### 🌿 Naturalistic learners - Present: incidentally — progressive discovery reduces token consumption, which is a genuine compute-efficiency gain. - Improve: the efficiency framing is entirely about cost and accuracy, never resource use. **Otherwise not applicable to this source.** ### 📊 Accessibility Assessment #### Screen reader semantics - Present: standard blog structure with headings and lists; the priority-areas diagram has descriptive text naming all five areas in the captured content. - Improve: verify that description is actual alt text rather than adjacent prose. Maps to **WCAG 2.2 A 1.1.1 Non-text Content**. #### Keyboard navigation - Present: standard article links. - Improve: not applicable to this source. #### Contrast and readability - Present: conventional documentation-site typography. - Improve: not assessable from captured text; verify against **1.4.3**. #### Text resizing and reflow - Present: standard responsive layout expected for a documentation blog. - Improve: the priority-areas diagram is the element most likely to break at high zoom; verify against **1.4.4** and **1.4.10**. #### Media and captions - Present: one diagram; no audio or video. - Improve: nothing significant. #### Forms and interactions - Present: not applicable to this source. - Improve: not applicable to this source. #### Standards reference - No significant gaps identified. The one thing worth checking is the diagram's alt text, since it carries the document's organising structure — if it is decorative in markup, the five-area framing is lost to screen reader users. ### 🌍 DEIB Assessment #### Cultural breadth - Present: an international standards-body orientation by construction — IETF and WIMSE engagement implies broad participation, and Working Groups are open. - Improve: no mention of language coverage in SDK documentation despite the SDK section emphasising documentation across "every platform and language we support" — where "language" plainly means programming language, not human language. #### Inclusive language - Present: neutral and precise; collective voice ("we," "our community") rather than individual attribution. - Improve: **acronym density is the real barrier.** DPoP, ID-JAG, WIMSE, SEP, WG, IG arrive unexpanded. For a document inviting new contributors, that gates participation to people already inside. #### Neurodiversity support - Present: excellent structure — five clearly delineated sections with consistent internal shape, a summary diagram, and a discrete participation section. - Improve: nothing significant. This is well-organised technical writing. #### Representation - Present: collective authorship credited to Core Maintainers and community, with each area naming responsible maintainers — accountability is distributed and visible. - Improve: the named maintainers do not appear in the post itself, only in the linked roadmap, so a reader cannot see who holds what without a second click. #### Psychological safety - Present: genuinely good. The prioritisation notice is candid rather than evasive — "maintainer review time is scarce" is an honest admission of constraint rather than a pretence of unlimited capacity. SEP-2133 explicitly lowers the barrier to contribution by allowing experimentation before formalisation. - Improve: telling contributors their off-roadmap proposal will be deprioritised is honest but discouraging; there is no stated path for genuinely valuable off-roadmap work beyond waiting. ### ✅ Logical Validity #### Strong reasoning - **Problem-first structure throughout.** Each area states what fails before naming the work. The two best instances — "MCP authorization today is built around a person approving access in a browser" and the hundred-tools sentence — are models of concise problem statement that make the proposed work evaluable. - **Promotion history as evidence.** Justifying priorities by noting they were previously "on the horizon" and "have since matured enough" demonstrates a functioning pipeline rather than asserting one. - **Composition review before hardening, area 1.** Recognising that primitives must "work well together" and scheduling a cross-Working-Group review is genuine design discipline — most protocols discover interaction problems after the primitives are immovable. - **Building on existing standards, area 3.** Choosing OAuth-family mechanisms and engaging IETF upstream, rather than inventing an identity model, is well-reasoned: it avoids creating something the rest of the industry must bridge to. - **"Opinionated path," area 3.** Correctly identifies that standards-compliance alone produces incompatible implementations, and that someone must choose. Choosing is the harder and better call. - **Honest constraint disclosure.** "Maintainer review time is scarce and goes to the roadmap first" states a real limit plainly instead of leaving contributors to infer it from silence. #### Fallacies - **Unsupported empirical claim** — "tool selection tends to get worse as the list grows." *Weakness:* this is the central justification for progressive discovery, it is stated as established fact, and no evidence or citation is offered. It is widely believed and plausibly true, which is exactly why it should be measured before a protocol is designed around it. *Fix:* cite evaluation data, or mark it as the working hypothesis it currently is. - **Vagueness on the load-bearing term** — "opinionated path" for agent identity. *Weakness:* the word doing the most work is undefined. Whether alternative standards-compliant approaches become non-conformant or merely unsupported is a materially different outcome for implementers, and the roadmap does not say. *Fix:* state the conformance consequence. - **Absence of temporal commitment** — "over the coming months" is the only timeframe anywhere. *Weakness:* honest for community-driven work, but adopters must make deployment decisions and cannot. The security area additionally depends on IETF timelines, compounding the uncertainty without acknowledging it. *Fix:* indicate relative sequencing even without dates. - **Missing dependency structure** — five areas presented as parallel. *Weakness:* several plainly interact (result contract standardisation and progressive discovery both concern what the model sees; transport unification affects SDK surface), and treating them as independent obscures sequencing risk. *Fix:* note the dependencies, since the composition review in area 1 shows the maintainers think this way already. - **Assertion without mechanism (minor)** — the claim that unifying on one transport "lets us simplify MCP server and client development even further." *Weakness:* plausible and unquantified; running HTTP semantics over stdio has its own costs that go unmentioned. *Fix:* acknowledge the tradeoff. #### Tone of voice - Collective and institutional — "we," "our community," "Core Maintainers together with" — appropriate for a governance document and consistent with its collaborative claims. - Precise and restrained; problems are named without drama and without overselling the fixes. - Candid where it matters, notably about scarce review capacity and about current practice ("pasted API keys and long-lived tokens") being inadequate. - Invitational throughout, with concrete routes rather than generic encouragement to participate. - Unhurried — no urgency manufactured, no competitive positioning, no claims about what this unlocks. Unusual and welcome for a protocol announcement. ### 🛡️ DARVO Analysis - **Deny:** Not present. The document does the opposite of denial — it names current shortcomings directly, including that authorization "is built around a person approving access in a browser" and that result handling "falls a bit short." - **Attack:** Not present. No person, project, or competing approach is criticised anywhere. - **Reverse victim/offender:** Not present. No accusatory or defensive dynamic exists in the material. - **Emotional cues and rhetoric:** Minimal by design. The only rhetorical pressure is the prioritisation notice, which is a statement of constraint rather than persuasion. - **Assessment:** DARVO is **not applicable to this source** — a governance and planning document with no accusatory dynamic. Worth noting positively that it names its own protocol's current inadequacies plainly, which is the opposite posture. ## 🎯 Conclusion - **Bottom line.** The organising principle is **convergence on existing infrastructure rather than parallel invention** — one HTTP-native transport that makes an MCP server "no different from any other HTTP workload," OAuth-family standards for identity with upstream IETF engagement, and one result contract replacing several. That is a maturing protocol making the unglamorous correct choices. - **Most consequential for practitioners: progressive discovery.** Tool-surface bloat is the constraint people are hitting now, and it has two costs — tokens spent on definitions nobody needed, and **selection accuracy degrading as the catalogue grows**. The second is the one that quietly makes integrations worse with no obvious cause. It is also the least mature item on the roadmap, and clients are already approximating it, so the protocol is codifying practice rather than leading it. - **Most consequential structurally: agent identity.** Three cases fail under browser-consent authorization — cloud workloads with their own identity, absent users, and **scope-reducing delegation to sub-agents**, which currently has no expression at all. The honest framing of what it replaces — "pasted API keys and long-lived tokens" — is an accurate description of most deployments today, including probably yours. - **The line worth carrying beyond MCP:** developers now "build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work." **Documentation is agent context now.** Ambiguity used to cost one developer twenty minutes; it now generates plausible wrong code at scale. That applies to every library and every developer-facing doc set, not just this one. - **What to hold lightly.** No dates anywhere, and the security work partly depends on IETF pace. The claim that selection degrades with catalogue size is the load-bearing justification for a whole priority area and is asserted without evidence — believable, widely repeated, and still unmeasured. And "opinionated path" leaves unstated whether alternative approaches become non-conformant or merely unsupported. - **Next steps for readers.** Audit how many tools your MCP servers expose — that number is a live cost today. Audit where you rely on pasted keys and long-lived tokens, and keep write access gated until the identity work lands. If you want to contribute, **SEP-2133** is the route worth knowing: experiment in an `experimental-ext-` repository first, then propose. It is the mechanism that stops the process selecting for specification-writers over implementers. ## 🔄 Refactor Appendix — The New MCP Roadmap > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Large tool catalogues degrade selection, not just cost > [!quote] > 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 **Context & use**: - Two distinct costs, and the second is the damaging one — accuracy degrading with catalogue size makes integrations quietly worse with no obvious cause. The stated justification for progressive discovery, and asserted without evidence despite being load-bearing. Directly relevant to any MCP server exposing many abilities. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Agent callers break browser-consent authorization > [!quote] > MCP authorization today is built around a person approving access in a browser. **Context & use**: - Fails for three named cases: cloud workloads with their own identity, agents acting for an absent user, and **scope-reducing delegation to sub-agents** — the third having no current expression at all. What it replaces, in their words: "pasted API keys and long-lived tokens." **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H3] Documentation accuracy now decides generated-code correctness > [!quote] > many developers build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work with minimal friction **Context & use**: - Docs are agent context, not just human reading material. Ambiguity used to cost one developer twenty minutes; it now produces plausible wrong code at scale. Generalises to every library and doc set. Pairs with this batch's recurring finding that agent effectiveness is bounded by the surfaces we provide. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H4] Experiment before formalising, via designated repositories > [!quote] > SEP-2133 lets any WG or IG experiment in an experimental-ext- repository before a formal SEP **Context & use**: - The underrated governance item. A process that only accepts fully-formed proposals selects for people with time to write specifications over people with working implementations. This inverts that. Reusable pattern for any standards-shaped project. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Interface surface area has an accuracy cost, not only a cost cost **Claim** (one sentence, Courtney's voice): Expanding the set of options presented to a decision-maker degrades the quality of the choice, so surface area must be curated rather than merely paid for. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for models selecting among tools and, by the same mechanism, for humans selecting among options — the classic choice-overload result. Weakens where options are strongly typed or hierarchically organised so the effective choice set stays small, which is precisely what progressive discovery attempts. Currently asserted rather than measured in the MCP case, so hold it as a working hypothesis. **Links** (≥1 with annotation): - [[Progressive-disclosure]] — because extends - [[Demo-the-twenty-percent-that-carries-the-value]] — because applies-in a different domain - [[Choice-overload]] — because evidence-for **Optional**: `proof_state: working` <!-- atomicity: 1 idea ✓ --> #### [P2] Documentation is now machine input, so ambiguity scales **Claim** (one sentence, Courtney's voice): When documentation is consumed by agents generating code rather than by people reading it, inaccuracy stops costing one reader some time and starts producing confidently wrong output at volume. **Evidence pointer**: [[#H3]] **Scope & conditions**: Holds wherever agents are pointed at reference material to generate implementations. The consequence is that documentation accuracy becomes an engineering-quality control rather than a communication nicety, and that conformance testing of docs against behaviour becomes worth doing. Weakens where agents can execute and verify against the real system, which substitutes empirical checking for documentary trust — which is the same verification argument from a different direction. **Links** (≥1 with annotation): - [[Verifiability-bounds-achievable-quality]] — because contrasts on where correctness is established - [[A-published-skill-propagates-its-omissions]] — because extends - [[Specify-style-as-measurement-rather-than-description]] — because applies-in writing <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] "Tool selection gets worse as the list grows" is asserted across the whole industry and measured by nobody, while protocol design decisions are being made on it. Clean experiment: same tasks, catalogue padded with irrelevant tools, measure selection accuracy. — https://blog.modelcontextprotocol.io/posts/mcp-roadmap/ #fleeting #articleseed - [F2] Scope-reducing sub-agent delegation has no expression in current auth models. That is a governance primitive as much as a technical one — it's how you bound what automation may do on your behalf. — #fleeting #xref - [F3] Audit how many tools my own MCP servers expose, and where I'm still using long-lived tokens. Both are live costs today. — #fleeting #inbox - [F4] SEP-2133 (experiment before formalising) is a governance pattern worth stealing for WordPress feature plugins — it's roughly what Accessibility Lab is doing informally, without the designated mechanism. — #fleeting #addendum - [F5] WooCommerce extended MCP abilities across all its extensions. That's exactly the pattern that hits the hundred-tool wall. Worth flagging to whoever owns WP MCP surface design. — #fleeting #share ### → Things 3 (max 2 actions) - [ ] Audit tool counts and token cost across my connected MCP servers — tooling #things - [ ] Replace long-lived MCP tokens where possible and keep write abilities gated until DPoP lands — security #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/The New MCP Roadmap.md|The New MCP Roadmap by blog.modelcontextprotocol.io]] ## Highlights - [MCP authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) today is built around a person approving access in a browser. That works well for interactive clients, but more and more of 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. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens. ([View Highlight](https://read.readwise.io/read/01m0sz0ebmm889hwam43a2y3y1)) - Note: [H2] Agent callers break browser-consent authorization. Three failing cases: cloud workloads with own identity, absent users, and scope-reducing delegation to sub-agents — the third having no expression at all today. What it replaces, in their words: "pasted API keys and long-lived tokens." - Tags: atom/literature/h2, share - The other challenge we need to address for primitive use is their ever-growing scale. 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. We’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. ([View Highlight](https://read.readwise.io/read/01m0sz04756zp9xxjtmm1tp1p4)) - Note: [H1] Large tool catalogues degrade selection, not just cost. Two distinct costs, and the second is the damaging one — accuracy degrading with catalogue size makes integrations quietly worse with no obvious cause. Load-bearing justification for progressive discovery, asserted without evidence. - Tags: atom/literature/h1, articleseed - Our SDKs are how developers experience MCP. We are investing in their ergonomics and their [conformance with the specification](https://modelcontextprotocol.io/community/sdk-tiers#conformance-testing), and in making them intuitive and well-documented across every platform and language we support. This is even more important now that many developers build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work with minimal friction. ([View Highlight](https://read.readwise.io/read/01m0sz0qhfd3x0bnq7g79b8cqe)) - Note: [H3] Documentation accuracy now decides generated-code correctness. Docs are agent context, not just human reading material. Ambiguity used to cost one developer twenty minutes; it now produces plausible wrong code at scale. Generalises to every library and doc set. - Tags: aphorisms, atom/literature/h3