Five weeks after the 2026-07-28 release turned remote MCP servers into ordinary HTTP workloads, MCP Core Maintainers David Soria Parra and Den Delimarsky published an updated roadmap on August 22, 2026. It doesn't announce a new spec version — it names what the Core Maintainers and Working Groups will actually spend review time on next, and which Specification Enhancement Proposals (SEPs) get expedited attention as a result.
For anyone building MCP servers, clients, or agent stacks on top of the protocol, this roadmap is the closest thing to a public backlog: five priority areas, each with a named owner and a working group behind it.
TL;DR
| Question | Answer |
|---|---|
| Who published this? | Core Maintainers David Soria Parra and Den Delimarsky, with input from Working Groups and the community |
| When? | August 22, 2026 |
| Does it change the spec today? | No — it sets priority areas for SEP review, not a new release |
| How many priority areas? | Five: messaging, transport, identity, primitives, SDKs |
| Is this the first roadmap? | No — it updates a prior roadmap; several items graduated from "on the horizon" to full priorities |
| Does it require new auth work from server builders? | Eventually — DPoP and agent identity are prioritized, but adoption is opt-in and gradual |
| What's the single most concrete deliverable? | Maturing the Tasks extension (SEP-2663) so long-running work moves into the core spec |
The five priority areas, explained
The roadmap groups work the maintainers were already circling — server-initiated events, result-type cleanup, agent identity — into five named priorities, each owned by specific Core Maintainers and Working Groups.
1. Agentic messaging primitives
Modern agent loops don't fit request/response. A loop can run for minutes, a server may need to push a streamed result mid-task, and a client sometimes needs to steer work that's already in flight. MCP has been adding pieces to handle this — Tasks, subscriptions/listen, progress notifications — but they haven't been reviewed together as one coherent system.
This priority area covers three concrete threads:
- Server-initiated events — webhooks and channels so clients stop polling for results.
- A composition review across the Agents, Transports, and Triggers & Events Working Groups, checking that these primitives compose cleanly rather than accumulating as one-off additions.
- Maturing the Tasks extension (SEP-2663) toward inclusion in the core specification.
If your server already runs long jobs — a video render, a multi-step research task, a batch job — this is the area to watch for a standardized way to report progress without holding a stream open the whole time.
2. HTTP-native transport unification and hardening
We covered the 2026-07-28 release in depth when it shipped: it dropped Mcp-Session-Id and sticky sessions in favor of a stateless request/response core, which meant a remote MCP server could finally run behind any ordinary load balancer or on serverless infrastructure — the same way any other HTTP API does.
The new roadmap extends that model to cover local servers speaking Streamable HTTP over stdio — collapsing the historical split between "local stdio server" and "remote HTTP server" into one transport model. The stated goal is to simplify both server and client development by removing the need to support two fundamentally different transport code paths.
3. Agent identity and enterprise-ready security
This is the priority area drawing the most scrutiny, and for good reason. MCP authorization today assumes a person approves access in a browser via OAuth — that model breaks down when the caller is a cloud workload with its own identity, acting on behalf of an absent user, or a sub-agent that should hold narrower authority than the agent that spawned it.
The roadmap commits to:
- Finalizing Demonstrating Proof of Possession (DPoP) and driving adoption — binding an access token to a client-held private key so a stolen bearer token alone isn't enough to use it.
- Workload Identity Federation as the mechanism for a client to obtain a bearer token without a long-lived credential.
- The ID-JAG grant behind Enterprise-Managed Authorization — the same mechanism we detailed in our Claude enterprise-managed auth + Okta piece, where employees inherit MCP connector access through their identity provider instead of a per-connector OAuth flow.
- Standard token exchange, plus continued engagement with the IETF OAuth and WIMSE working groups.
The practical shift: instead of a pasted API key sitting in an MCP config file, an agent presents a DPoP proof alongside a WIF-issued token, and the resource server verifies both without holding any additional state. Pair this with our MCP security guide — DPoP tightens transport-level auth, but prompt injection, confused-deputy, and over-broad tool scoping are still separate threat classes to defend.
4. Improved primitives
Two distinct problems live under this heading.
Result type ambiguity. A tools/call response can carry the same output in more than one form, and today a server developer has no reliable way to know which form a given client will actually render. The roadmap commits to standardizing on one clear contract so servers stop guessing.
Tool catalog scale. Connect to a server with a hundred tools and the model pays the context cost for the entire surface before the user asks a single question — and tool selection reliably gets worse as the list grows. We wrote about the selection side of this in MCP tool descriptions and reliable agent selection; the roadmap's progressive discovery effort attacks the other half of the problem, letting a server expose a small entry point and reveal more of its catalog only as the conversation narrows.
5. Improved SDK developer experience
The least flashy priority, and arguably the one with the broadest reach: investment in SDK ergonomics, spec conformance, and documentation across every language MCP supports. The maintainers note this matters more now that many developers build MCP clients and servers by pointing a coding agent at the SDK source rather than reading docs line by line — which makes clear APIs and accurate reference material a direct lever on whether generated code works on the first try.
What Hacker News pushed back on
The announcement drew 77 points and a long comment thread within hours, and the pushback clustered around three recurring arguments.
Enterprise auth complexity vs. actual adoption. Multiple commenters questioned how many MCP server maintainers will actually implement DPoP, Workload Identity Federation, and ID-JAG end to end, versus continuing to ship a long-lived bearer token and calling it done. One reply defended the complexity directly: without workload identity, teams either slow down agentic loops with interactive OAuth or spin up service accounts everywhere, which undermines the "who did this" answer that compliance requires.
MCP vs. plain REST + OpenAPI + skills.md. This was the thread's most-argued point. Several commenters — including one running a company that generates its MCP server directly from an OpenAPI spec — asked why MCP earns a bespoke protocol when a documented REST endpoint plus a markdown instructions file does the same job for any agent with code-execution access. The strongest counter-argument: MCP's real value isn't the wire format, it's centralized distribution — a way to update tool instructions on someone else's machine without inventing your own skill-syncing protocol. We cover this exact framing in CLAUDE.md vs SKILL.md vs MCP.
Praise for HTTP-native unification, with a coda about "code mode." The 2026-07-28 transport work drew broad approval — one commenter called treating MCP servers like "one of the more bone-headed" early design choices, now fixed. But several also pointed to Cloudflare's code-mode pattern (letting an agent write and execute code against APIs directly, inside a sandbox) as a lower-overhead alternative to raw tools/call round-trips for agents that already have a code execution environment — a reminder that MCP is one integration pattern among several, not the only one.
What builders should do this week
- If you run long jobs through MCP, start tracking Tasks (SEP-2663) — it's the most concrete near-term deliverable in the messaging area.
- If you self-host a remote server, revisit your deployment now that local and remote transports are converging — see our MCP 2026-07-28 migration checklist.
- If you're on Claude Enterprise or another IdP-backed setup, read up on ID-JAG and Enterprise-Managed Authorization before DPoP lands — the Okta integration guide covers the current shape of that flow.
- If your server exposes more than ~20 tools, don't wait for progressive discovery to ship — apply the scoping and description discipline from our tool descriptions guide now.
- If you're choosing between MCP and a plain REST + skills.md setup, weigh distribution needs specifically — see RAG vs MCP for the broader integration-pattern comparison, and browse MCP server directories to see what's already shipped as an MCP server today.
If you're considering proposing a SEP, the roadmap explicitly says proposals inside these five areas get expedited review — everything else competes for the same scarce maintainer time. Raise it with the relevant Working Group first.
If you'd rather learn this hands-on than read the SEP tracker, our live MCP Bootcamp: Connect Claude to Everything runs Oct 31–Nov 1, 2026 — two live sessions covering MCP architecture, wiring at least two real MCP servers into your own environment, building a custom server, and the security and team-governance patterns this roadmap is pushing toward.
Related on explainx.ai
- What is MCP? Model Context Protocol architecture guide
- MCP 2026-07-28: stateless core, Apps, Tasks, enterprise auth
- Claude enterprise-managed auth: zero-touch MCP via Okta
- MCP security guide 2026
- MCP tool descriptions: writing them for reliable agent selection
- CLAUDE.md vs SKILL.md vs MCP
- RAG vs MCP: the complete comparison
- Top 10 MCP server directories & registries
Official
- Model Context Protocol blog
- MCP specification
- SEP-2663 — Tasks extension
- SEP-2133 — experimental extensions
This roadmap sets direction, not a finalized spec — SEP status, working-group ownership, and timelines can shift as proposals move through review. Verify current status on the official MCP roadmap and specification pages before committing engineering time.