Dora NodaOn August 22, 2026, MCP core maintainers David Soria Parra and Den Delimarsky published The New MCP Roadmap: five priority areas for the next specification release and beyond, with no target dates and no version numbers attached. If you run your own MCP servers — your own deploy-from-chat tool servers on machines you own, not a managed gateway — the roadmap is an early-warning signal, not a migration order. The practical question it leaves unanswered is which priorities demand work from you now and which you can safely watch from a distance.
Here is the answer up front, ranked by urgency for a self-hosted operator:
| Priority | Verdict | Migration cost |
|---|---|---|
| 3: Agent identity and enterprise-ready security | Act now — audit auth flows | High |
| 2: HTTP-native transport unification and hardening | Plan the local-side migration | Medium |
| 4: Improved primitives (result contracts, progressive discovery) | Design for it now, refactor later | Medium |
| 1: Agentic messaging primitives | Watch — do not build a custom event layer | Low |
| 5: Improved SDK developer experience | Watch — adopt the conformance harness when it ships | Low |
The rest of this post is the priority-by-priority reasoning behind that table: what each item changes about auth, transport, or tool governance, where the gaps stay even after all five ship, and how to sequence adoption on owned infrastructure without chasing a moving protocol target.
What already shipped: the stateless baseline
The five priorities build on the 2026-07-28 specification release, which did the heaviest structural work. Protocol-level sessions and the initialization handshake are gone (SEP-2575, SEP-2567), so a server scales horizontally without holding state. Clients can call server/discover to learn supported versions and capabilities before doing anything else, list results are cacheable with TTL metadata (SEP-2549), Tasks became an official extension (SEP-2663), and the Multi Round-Trip Requests pattern (SEP-2322) replaced server-initiated requests so elicitation works on stateless servers.
For a self-hoster, the operational meaning of that release is simple: a remote MCP server is now no different from any other HTTP workload. No session store, no sticky routing, a fresh server instance per request — the standard stateless deployment shape, horizontally scalable behind any load balancer you already run. The August roadmap assumes this baseline everywhere. If you have not yet moved off pinned sessions and the deprecated SSE transport, do that first; everything below is sequenced after it.
Priority 3 first: agent identity is the act-now item
MCP authorization today is built around a person approving access in a browser. That works for interactive clients and breaks down the moment the caller is an agent running as a workload: no human present to click through a consent screen, possibly delegating narrower authority to sub-agents. The roadmap's answer is to standardize how servers recognize and trust agent identities, built on existing standards rather than pasted API keys and long-lived tokens.
Concretely, the work covers three mechanisms.
- DPoP (Demonstrating Proof of Possession, RFC 9449, finalized September 2023) binds an access token to a specific cryptographic key, so a stolen token cannot be replayed from a different client — a meaningful upgrade over bare bearer tokens, which are effectively cash.
- Workload Identity Federation (via spec PR #1933) replaces stored service-account credentials with short-lived tokens issued by a trust anchor you already have, such as your cloud provider or Kubernetes.
- Standard token exchange (RFC 8693) lets an agent swap one token type for another without re-authenticating.
The maintainers are also engaging the IETF OAuth and WIMSE working groups as those standards evolve — note that WIMSE is still active with no finalized RFC as of September 2026, so treat that leg as direction, not dependency.
Why act now, when none of this has shipped? Because this is the one priority with a clear destination, and the starting position is bad. The NSA's June 2026 advisory on enterprise MCP security catalogued eight risk categories including access-control gaps (authentication optional, no protocol-defined RBAC) and token lifecycle weaknesses (bearer token management largely unspecified). The audit you should run this month costs nothing against the spec: inventory every place your servers accept browser-OAuth flows or bare bearer tokens in machine-to-machine paths, and mark each as a future DPoP or federation migration. When SDK support lands, you will have a list instead of a surprise.
One boundary to internalize now, because it shapes the whole plan: the identity work solves agent-to-server trust — which workload is calling your server. It does not touch server-to-source credentials — what your server hands to Postgres, Salesforce, or your data warehouse to open the connection behind it. That second auth problem stays yours per source, per that source's own auth model, no matter what the roadmap ships. CData's enterprise explainer frames this as two parallel workstreams, and the framing is right: the agent-to-server leg has a spec destination to move toward, while the server-to-source leg is permanent operational work.
Priority 2: one transport to run
Streamable HTTP is already the standard for remote MCP servers since the 2026-07-28 release. Local servers still speak stdio: simple, fine for local dev, and untranslatable to remote deployment. Priority 2 extends Streamable HTTP to local servers as well — including Streamable HTTP over stdio — so there is one transport instead of two, and what you run locally behaves the same as what you run in production.
The migration math depends on where you stand. If your remote servers are already on Streamable HTTP, nothing changes on that side; the work is local test harnesses, SDK versions, and any stdio wrappers. If you are still on the pre-07-28 pattern of stdio plus the deprecated SSE transport, you are looking at a second migration after the first — plan it as one program, not two surprises.
Either way, the operational payoff of unification is real for a small team: one transport to monitor, scale, and debug, and a local setup that reproduces production behavior instead of approximating it. That is also the precondition for running the same server binary on a developer laptop and on your fleet without transport-specific branches in your deployment config.
Priority 4: tool result contracts and progressive discovery
Two separate items share this label, with different planning implications.
Tool result contracts. Today 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 will put in front of the model. Tool authors write defensively, clients handle results inconsistently, and models see more variation than they should. The roadmap standardizes one clear contract. The planning call: if you are building new tools today, orient toward the spec's direction; if you have a large existing catalog, do not refactor proactively — wait until the final definition exists, then migrate once.
Progressive discovery. 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 gets worse as the list grows. The spec's answer is progressive discovery: the server offers a small entry point and reveals more of its catalog as the conversation narrows. If you run a large tool catalog today, you have probably hand-rolled some version of this already; the roadmap is standardizing what teams built anyway. The timing matters in the opposite direction from result contracts: retrofitting progressive discovery onto a large catalog is more expensive than designing for it upfront, so new catalog work should assume a scoped-entry-point shape now.
Priorities 1 and 5: watch, do not build
Agentic messaging (Priority 1) extends the protocol past request-response into server-initiated events — webhooks and channels, so clients stop polling for results — with the Agents, Transports, and Triggers and Events working groups leading the design and the Tasks extension maturing toward the core spec. There is nothing to migrate here. The only decision is architectural: if your servers need to push events today, you are choosing between polling, a held connection, or a hand-rolled webhook. For anything you expect to stay client-agnostic, wait for the working groups to finalize the design before committing to a non-standard event layer — the migration cost of guessing wrong is real, and polling is a fine bridge.
SDK developer experience (Priority 5) covers ergonomics, documentation, and spec-level conformance testing — increasingly important now that many developers build MCP clients and servers by pointing an agent at the libraries. The conformance harness is the part worth your attention: today you test against your interpretation of the spec, not the spec itself, and servers passing the same suite will produce fewer of the subtle client-server incompatibilities that break pairs in production. Nothing to migrate; integrate the harness into CI when it ships and call it done.
The adoption sequence on owned infrastructure
Sequenced for a team running its own servers on machines it owns:
- Finish the 07-28 baseline. Stateless Streamable HTTP everywhere remote, off deprecated SSE. Every priority assumes this.
- Audit identity now (Priority 3). Inventory browser-OAuth and bare-bearer-token usage in machine-to-machine paths; plan the DPoP and Workload Identity Federation migration so SDK support unblocks execution, not discovery.
- Plan the local transport migration (Priority 2). One transport means local reproduces production; schedule stdio-wrapper and harness work against SDK support.
- Design catalogs for progressive discovery (Priority 4). Assume scoped entry points in new tool work; defer the result-contract refactor until the definition is final.
- Hold on messaging, watch SDK conformance (Priorities 1 and 5). Poll rather than hand-roll event delivery; add the conformance suite to CI on arrival.
After all five ship, three gaps stay on your side of the boundary: source credentials (each source's own auth model, managed per connector), per-user authorization inside the source (source-system RBAC does not flow through an MCP server unless you enforce it), and audit logging (reconstructing what an agent queried, on whose behalf, and when). These are not criticisms of the roadmap — they are the engineering work that was always yours. If anything, the roadmap makes the boundary cleaner: agent-to-server identity gets a standard, which makes the remaining server-to-source work more visible, not larger.
What this means for deploy-from-chat infrastructure
Step back and the direction is unmistakable: MCP is growing the identity, transport, and primitive infrastructure that production systems need, and each step makes a self-run server cheaper to operate. Stateless HTTP servers behind your existing load balancer. One transport from laptop to fleet. Agent identity without long-lived secrets to rotate. A standard event model you do not have to invent. None of it is dated yet, which is exactly why the sequence above front-loads the audit-and-design work that is valuable regardless of ship dates and defers every migration to a finalized definition.
If you are building the layer above the protocol — the deploy-from-chat tool servers that turn agent intent into running services — the roadmap is good news twice over: the servers get simpler to run, and the per-source governance work you do anyway becomes the durable differentiator no spec release commoditizes.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
