MCP Roadmap 2026: DPoP, HTTP over stdio, Progressive Discovery

The official Model Context Protocol (MCP) roadmap was updated on August 22, 2026, published at modelcontextprotocol.io. It lays out five priority areas that the Core Maintainers expect to focus on over the next six to twelve months, along with the main Specification Enhancement Proposals (SEPs) tied to each. As the roadmap itself states, this is not a set of firm commitments but a snapshot of current thinking. That said, SEPs falling inside a priority area get prioritized review and stand a better chance of being adopted, while SEPs outside the priority areas are not automatically rejected but face a longer queue and a higher bar for justification. For developers building MCP servers and clients, or teams evaluating an agentic infrastructure stack, this is useful signal for where the spec is likely to move and where design changes may land. This article walks through the five areas in turn.

MCP spec changes move through SEPs (Specification Enhancement Proposals). The roadmap indicates which areas' SEPs get prioritized review this cycle; individual Working Groups and Interest Groups actually own the work in each area. SEPs that gain Working Group support advance fastest, so inclusion in a priority area does not guarantee any specific SEP gets adopted, and SEPs outside the priority areas are not barred from being proposed either. The five areas below are best read as where the Core Maintainers plan to focus resources this cycle, not as a delivery schedule.

Agentic workloads need patterns beyond simple request/response: operations that take minutes, server-initiated pushes, streaming results, and mid-flight steering from the client. MCP currently answers "the server isn't done yet" in three separate ways — Tasks, subscriptions/listen, and progress notifications — spread across multiple Working Groups, without a shared lifecycle, cancellation model, or error representation. This cycle's focus is server-initiated events from the Triggers & Events Working Group: channels and subscriptions for push delivery, including webhooks, meant to reduce clients' reliance on costly polling. Alongside it, the Agents, Transports, and Triggers & Events Working Groups will run a composition review to check whether these still-emerging primitives, such as Tasks and Triggers, compose cleanly and actually fit concrete use cases. Work on Tasks (SEP-2663) continues in parallel, with the eventual goal of folding these extensions into the core protocol.

With the July 28, 2026 release, remote MCP servers effectively became ordinary HTTP workloads, carrying more transport-level information in headers and status codes. That has meant designing HTTP-native features twice — once for HTTP, once for stdio — while SDKs maintain two separate transport pipelines and protocol metadata ends up duplicated across HTTP headers and message fields, forcing servers to cross-validate. The centerpiece this cycle is HTTP over stdio from the Transports Working Group: making Streamable HTTP the sole binding, with local servers speaking it over stdin/stdout. The expectation is that HTTP/2 over stdio can deliver a multiplexed HTTP transport while preserving the security and lifecycle guarantees of a subprocess. The other pillar is caching: a recent revision (SEP-2549) added ttlMs and cacheScope to list results and resource reads, and the plan is to extend this toward ETags so that primitive results — tool calls in particular — can be versioned. Also under discussion: standardized error handling across all surfaces, capability scoping for tool lists in the wake of SEP-2575 (stateless MCP), and safe ways for servers to expose configuration options. This builds directly on the statelessness shift covered in MCP's July 28, 2026 Spec and the Move to Stateless.

MCP's authorization model was built around the assumption that a human is in front of a browser at the moment of consent. Increasingly, though, the caller is an agent: a cloud workload with its own identity, an agent acting on behalf of a user who isn't present, or a sub-agent that should be spawned with narrower permissions than its parent. Many existing MCP servers still rely on pasted-in API keys and long-lived refresh tokens. The Agent Identity Working Group, expected to form this cycle, will first work to finalize and drive adoption of DPoP (Demonstrating Proof of Possession, a cryptographic way to prove a client actually holds a token, aimed at stopping stolen tokens from being reused elsewhere). The second thread is agent identity and delegation — how an MCP server is reached using an agent's own identity or an identity delegated by a user. The focus areas named are Workload Identity Federation (SEP-1933), the Identity Assertion JWT Authorization Grant (ID-JAG) used in Enterprise-Managed Authorization, and RFC 8693 token exchange, coordinated with the IETF OAuth and WIMSE working groups. Human-presence attestation — distinguishing interactive clients from headless agents — is also under discussion, though not yet a settled spec.

tools/call currently allows returning both content and structuredContent at once, which the roadmap says has confused server and client implementers alike and produced divergent implementations. There's also been recurring feedback that there isn't a good way to steer clients through large numbers of tools and resources. The Core Primitives Working Group, expected to form this cycle, will start with tool result shape: redesigning the tools/call interface to close the gap in return-type fidelity and clean up how structured and unstructured output are handled. Next is progressive discovery, letting clients learn a server's tools and resources incrementally rather than loading the full catalog up front — expected to interact with the caching work above. Third is primitive annotations: applying content annotations (which declare a piece of content's intended audience and priority) to tool results and resources as well, potentially resolving the visibility confusion SEP-2200 flags. The roadmap is candid that this hasn't seen much adoption and its purpose isn't widely understood, so deprecation is on the table if it doesn't prove useful. Separately, the File Uploads Working Group continues work on scoped file operations — range reads, hierarchical listing — and filesystem-like resource semantics.

SDKs, reference servers, and quickstarts are currently maintained by hand. The roadmap's goal is to treat the spec and a human-reviewed conformance test suite as the source of truth, regenerating and reverifying these artifacts on every release instead of patching them afterward. This cycle, the SDK Working Group and Core Maintainers will work on the extension contract: which role (host, client, server, or agent) an extension attaches to, what each role does when a capability is declared, how much of this SDKs should support natively, how extensions get packaged, treating new capabilities as versioned changes to an extension, and treating auth as its own concern. The second thread is the generated-artifacts experiment: generating candidate Tier 1 SDKs and their accompanying quickstart examples directly from the spec, validating them against the conformance test suite, and publishing findings — including a recommendation on which layers should be deterministic codegen versus model-assisted — for the next cycle. Ownership and freshness expectations for the reference server and quickstart repos will also be revisited, and spec ambiguities surfaced by generation failures will be treated as documentation bugs. This bears directly on the accuracy of quickstart material such as the Claude Code MCP Integration Guide.

- Remember the roadmap describes intent, not a commitment, and avoid a large-scale rewrite based on it alone
- If you've built your own workarounds for long-running operations or server-initiated notifications, keep an eye on the progress of server-initiated events and Tasks
- If your SDK or implementation maintains separate stdio and HTTP transport code paths, keep them loosely coupled so they can converge once HTTP over stdio is finalized
- Take stock of any authorization logic that depends on pasted API keys or long-lived refresh tokens, with DPoP and agent identity/delegation on the horizon
- If your implementation returns both content and structuredContent from tools/call, be aware it may fall within the scope of the tool result shape redesign
- Check the official participation paths — filing or commenting on SEPs, joining a Working Group, or experimenting via an experimental-ext- repository under SEP-2133

Discussion details and per-SEP progress are expected to be updated on the official roadmap (https://modelcontextprotocol.io/development/roadmap ) over time. If you're thinking through permission design for an agent platform, the Agent Plugins 1.0 Standard is also worth a look.