MCP's new roadmap: five priorities after the stateless spec

On 22 August 2026, MCP lead maintainers David Soria Parra and Den Delimarsky published an updated roadmap for the Model Context Protocol. It names five priorities: agentic messaging primitives, HTTP-native transport unification, agent identity and enterprise security, improved primitives, and SDK developer experience. The timing matters. The roadmap lands four weeks after the 2026-07-28 specification release turned the protocol core stateless, and it tells you where the maintainers intend to push next. If your team runs MCP servers on Azure Container Apps or AKS behind Azure API Management, secured with Entra ID, this is the document that should shape your next two quarters of platform work: it separates the parts of your MCP stack you should invest in now from the parts where building something custom today means rework later.

Where the protocol stands after 2026-07-28

A quick recap, because the roadmap only makes sense against the July release. The 2026-07-28 specification removed the initialize handshake and protocol-level sessions. In the release post's words, "every request is self-describing, with an optional discovery call for clients that want capabilities up front." A remote MCP server now runs behind a plain load balancer with no shared state, no sticky sessions and no Redis session store. The release also shipped:

• Multi Round-Trip Requests (MRTR), which replace server-initiated requests that needed an open stream. A tool call can pause for a mid-call user confirmation and resume without a persistent connection.
• Header-based routing: the method and tool name travel in HTTP headers, so gateways can route, throttle and authorize without parsing JSON-RPC bodies.
• Cacheable list results: tools/list, prompts/list and resources/list responses carry ttlMs and cacheScope hints, so clients and gateways know how long a catalog stays valid.
• Authorization hardening: RFC 9207 issuer validation, plus a shift away from Dynamic Client Registration towards Client ID Metadata Documents.
• Formal extensions: Tasks and MCP Apps live outside the core as official extensions, and Roots, Sampling and Logging entered a deprecation window with a twelve-month minimum offramp.

Adoption is no longer a question. The TypeScript and Python SDKs have each passed one billion total downloads, all four Tier 1 SDKs (TypeScript, Python, Go, C#) support the new specification, and the Rust SDK is in beta. Whatever you think of individual design choices, MCP is the integration layer your agents will speak. The roadmap is therefore worth reading the way you would read a Kubernetes or .NET roadmap: as advance notice of where your own platform work should and should not go.

The five priorities, read as an Azure platform engineer

1. Agentic messaging primitives

The maintainers open with a blunt observation: "Modern agentic workloads no longer fit the standard request-and-response pattern." An agent that kicks off a long-running job wants to be told when it finishes. A server that watches a data source wants to push changes to interested agents. MCP has been growing towards this with Tasks, the subscriptions/listen mechanism and progress notifications, and the roadmap commits to more: server-initiated events, webhooks, channels, a composition review across the Agents, Transports, and Triggers & Events working groups, and continued maturing of the Tasks extension.

The practical guidance for an Azure team is restraint. If you need long-running work today, use the Tasks extension and persist task handles client-side, keyed into whatever durable backend you already run: a Durable Functions instance ID, a Service Bus correlation ID, a Cosmos DB row. What you should not do is invent a proprietary push channel between your MCP servers and your hosts, because the protocol is clearly heading towards standardized webhooks and channels. When those land, they will map naturally onto infrastructure you already have, such as Event Grid for fan-out and API Management for webhook ingress. Custom push plumbing built now is rework scheduled for later.

2. HTTP-native transport unification

The stateless core collapsed the operational difference between an MCP server and any other web service. The roadmap states it directly: "A remote MCP server is now no different from any other HTTP workload." The next step is stretching that model to cover the remaining deployment modes, "including local servers speaking Streamable HTTP over stdio." In other words, one wire protocol everywhere, with stdio reduced to a byte pipe that carries the same HTTP-shaped traffic.

For teams maintaining both a local developer mode and a remote production deployment of the same server, this is the most quietly valuable item on the list. Today you often carry two code paths: a stdio transport for local use in IDEs and desktop hosts, and a streamable HTTP transport for the Container Apps deployment. Unification means one code path, one set of integration tests, and gateway-style middleware (auth, logging, header inspection) that behaves identically in both modes. It also strengthens the case for treating MCP servers as ordinary services in your platform: same Bicep modules, same APIM policies, same Application Insights wiring as every other API you run.

3. Agent identity and enterprise security

This is the section EU enterprise teams should read twice. The roadmap covers "finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation." The framing is that agents are cloud workloads with identities of their own, and that delegation should run on standardized mechanisms rather than API keys.

Azure teams have a head start here, because the primitives already exist in the platform. Entra Workload ID and federated credentials let a workload exchange a platform-issued token for access without any long-lived secret. If your agents currently authenticate to MCP servers with static keys stored in Key Vault, the direction of travel is clear: move service-to-service MCP traffic onto managed identities and federated credentials where you control both ends, and treat the remaining API keys as technical debt with a named owner. DPoP is the complementary piece, binding a token to the client that holds the key so a stolen bearer token stops being enough. Do not build a custom proof-of-possession scheme while DPoP is being finalized in the protocol; do make sure your token-handling code is structured so adding a DPoP layer later is a bounded change.

4. Improved primitives: progressive discovery and one result contract

Two problems get named. First, large tool catalogs are expensive: a model connected to an enterprise-wide MCP estate pays context cost for every tool definition before the conversation even starts. The roadmap starts "a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows." Second, tool results are ambiguous: a tools/call response can carry the same output in more than one form, and the maintainers want to standardize on one clear contract.

You can prepare for progressive discovery without waiting for it. The enterprises we see struggle with MCP at scale are the ones that shipped one giant server with eighty tools. Decompose by domain now: an invoicing server, an HR-data server, a document-search server, each with a catalog small enough to describe cheaply. That structure is exactly what a progressive-discovery world rewards, and it already pays off today through the 2026-07-28 cacheable list results, since a stable, small catalog with a generous ttlMs is cheap for every host that connects. On the result-contract side, audit your servers for tools that return the same payload as both text and structured content. Pick the structured form as canonical now, and the eventual standardization becomes a no-op for you.

5. SDK developer experience

The least glamorous priority may matter most for procurement. The maintainers are investing in SDK ergonomics, specification conformance testing and documentation. Conformance testing is the item to watch: once an official conformance suite exists, "does your product implement MCP correctly?" becomes a checkable claim rather than a vendor assertion. For teams evaluating agent platforms, gateways or third-party MCP servers, that is a concrete requirement you will be able to write into an evaluation matrix. Until then, the safe posture is unchanged: build on Tier 1 SDKs, pin versions, and track release notes, since the SDKs are where specification changes become your API surface.

Adopt, prepare, watch: sorting the roadmap into work

• Adopt now (shipped in 2026-07-28): stateless deployment with session affinity off and Redis session stores decommissioned; APIM policies keyed on the MCP routing headers; ttlMs-aware catalog caching; issuer validation per RFC 9207; the Client ID Metadata Documents flow, which fits Entra ID far better than Dynamic Client Registration ever did; migration off Roots, Sampling and Logging inside the twelve-month window.
• Prepare (committed on the roadmap): Tasks-based async design with client-side handle persistence; workload-identity-based auth for agent-to-server traffic using Entra Workload ID and federated credentials; domain-decomposed servers with small catalogs, ready for progressive discovery; token handling structured so DPoP can be layered in.
• Watch (directional, do not pre-build): webhooks, channels and server-initiated events; custom proof-of-possession schemes; any bespoke push transport between servers and hosts; speculative work against the stdio-over-Streamable-HTTP unification before it lands in the SDKs.

The Swedish and EU angle

NIS2 and demonstrable access control. Swedish organisations in scope of NIS2 are being pushed towards access controls they can evidence, not just describe. An agent estate where every agent holds its own workload identity, tokens are short-lived and federated rather than static, and proof-of-possession binds tokens to holders is an estate a security auditor can reason about. The roadmap's identity work gives you standards-track names (DPoP, Workload Identity Federation) to cite in security documentation instead of describing home-grown key management. If you are writing the access-control section of an agent platform's risk assessment this autumn, align it with these mechanisms now, even where implementation comes later.

GDPR and the coming push model. Today's stateless request/response MCP keeps the data-flow story simple: a request arrives, is processed, and is gone, with no protocol-level session state to document. Server-initiated events and webhooks will change that. A server that pushes data to registered endpoints creates new egress paths, and each one belongs in your Article 30 records and, where personal data flows, in your DPIA. The right moment to write that documentation is when you enable the capability, not after. Put a review gate in your platform process now: no push-based MCP feature goes live without a data-flow update.

Procurement on firmer ground. For public-sector buyers running an upphandling, protocol governance is a real evaluation criterion. MCP now offers a public roadmap with named maintainers, working groups with defined scopes, a formal deprecation policy with a twelve-month minimum offramp, and a coming conformance suite. That is enough structure to write MCP compatibility into requirements with a straight face, and to ask vendors precise questions: which specification version, which extensions, what is the plan for the deprecated features, and will you commit to conformance testing when the suite exists.

Takeaways

• The 22 August roadmap confirms MCP's direction: stateless HTTP-native core, standardized agent identity, and messaging that outgrows request/response.
• Finish the 2026-07-28 migration first. Stateless deployment, header-based gateway policies and the auth changes are shipped and safe to build on.
• Design long-running work around the Tasks extension with client-side handle persistence; do not build custom push channels while webhooks and channels are being standardized.
• Start moving agent-to-server auth onto Entra Workload ID and federated credentials; structure token handling so DPoP is a bounded addition later.
• Decompose large MCP servers by domain now. Small catalogs are cheaper today and positioned for progressive discovery tomorrow.
• In the EU context: cite DPoP and Workload Identity Federation in NIS2-aligned security documentation, gate future push features on data-flow updates, and use the roadmap and deprecation policy as procurement evidence.

Sources

• MCP blog: An updated MCP roadmap (22 August 2026)
• MCP blog: The 2026-07-28 specification release