The Model Context Protocol maintainers published a new roadmap on August 22. It is not a minor housekeeping note. It names the next set of protocol priorities after the 2026-07-28 specification reset MCP around stateless HTTP.
The short version: MCP is moving from “connect an AI client to tools” toward a fuller application protocol for long-running agents, enterprise identity, scalable tool catalogs, and SDKs that agents can code against reliably.
If you build MCP servers, clients, gateways, or agent platforms, this roadmap is a useful signal for where to spend engineering time next.
What Changed Since the July Spec
The July specification made remote MCP servers behave more like normal HTTP workloads. Sessions were removed, requests became self-contained, and Streamable HTTP became the center of gravity for hosted servers. We covered those changes in the MCP 2026-07-28 specification breakdown.
The new roadmap answers the next question: once MCP is stateless and easier to deploy, what does the protocol need so agents can run real work for longer periods of time?
The maintainers list five priority areas:
- Agentic messaging primitives
- HTTP-native transport unification and hardening
- Agent identity and enterprise-ready security
- Improved primitives for tool results and discovery
- Better SDK developer experience
That is a practical list. It focuses less on adding flashy new surfaces and more on making the protocol dependable under production agent workloads.
1. Agentic Messaging Primitives
Basic request and response works for simple tool calls. It does not fit every agent workflow.
A real agent task might run for minutes, stream partial results, ask for input halfway through, or wait on an external event. Polling is a weak answer for that class of work. The roadmap names server-initiated events, webhooks, channels, Tasks, subscriptions, and progress notifications as pieces that need to work together.
This matters because long-running work is where agents become operationally useful. Research jobs, browser automation, code migrations, data syncs, and deployment workflows all need more than one synchronous tools/call response.
The important detail is composition. MCP already has pieces like Tasks and progress notifications. The roadmap says the working groups now need to make them fit together as one coherent pattern.
2. HTTP-Native Transport Becomes the Default Shape
The 2026-07-28 spec made remote MCP look like ordinary HTTP. The roadmap pushes that further. The maintainers want transport unification, including local servers speaking Streamable HTTP over stdio.
That sounds small, but it could reduce a lot of implementation drift. Today, MCP developers often think in two buckets: local stdio servers and remote HTTP servers. If the protocol can make those deployment modes feel more alike, client and server SDKs get simpler.
For developers choosing between transport options, this reinforces the direction we covered in what Streamable HTTP transport means for MCP and stdio vs SSE vs HTTP. HTTP is not just a remote hosting option. It is becoming the shared operating model.
3. Agent Identity Moves to the Center
This is the most important enterprise signal in the roadmap.
MCP authorization today is mostly built around a person approving access in a browser. That works for Claude Desktop or another interactive client. It gets messy when the caller is a cloud agent acting for a user, a background job with its own workload identity, or a sub-agent receiving narrower authority from a parent agent.
The roadmap points to DPoP, Workload Identity Federation, Enterprise-Managed Authorization, ID-JAG, standard token exchange, and ongoing work with OAuth and WIMSE groups.
In plain English: MCP wants agents to prove who they are without relying on copied API keys or long-lived bearer tokens. That is the right direction. Agent platforms need scoped delegation, revocation, audit trails, and proof that a token is being used by the entity it was issued to.
If you are building for internal company use, read this alongside how MCP auth works. The next wave of MCP security work will likely decide whether enterprises treat MCP as a serious integration layer or a developer-only experiment.
4. Tool Results and Tool Discovery Need Cleaner Contracts
The roadmap also calls out two practical problems with MCP tools.
First, tools/call results can carry output in more than one form. Server developers may not know which part of the response a client will show to the model. That creates inconsistent behavior across clients. A clearer result contract would make server output easier to test.
Second, tool catalogs are getting too large. A server with one hundred tools forces the model to inspect a lot of surface area before the user asks for anything specific. That costs tokens and can make tool selection worse.
Progressive discovery is the proposed direction: expose a smaller entry point, then reveal more tools as the conversation narrows. That fits how agents actually work. Start broad, identify intent, then load the relevant tool surface.
For background on the current shape of the interface, see what MCP tools are and what MCP tool annotations are.
5. SDKs Are Now Part of the Agent Experience
The roadmap closes with SDK developer experience. That may sound less exciting than agent identity or server events, but it is where many implementations succeed or fail.
A lot of MCP code is now written with help from coding agents. That means SDK APIs and docs are not only for humans. They are also training wheels for the agents generating server and client code. Clear examples, conformance tests, and stable abstractions directly affect whether generated MCP integrations work on the first pass.
This is also where AgentNDX readers should pay attention. As the protocol grows, the best MCP servers will not just expose useful tools. They will follow the spec closely, publish clear install paths, document auth, and behave predictably across clients.
What Builders Should Do Now
If you maintain an MCP project, the roadmap suggests a few near-term moves:
- Treat Streamable HTTP as the default path for new remote servers.
- Avoid hidden session state. Use explicit handles and resource IDs.
- Watch the Tasks extension and server-initiated event work if your server runs long jobs.
- Revisit auth design before enterprise customers ask for workload identity and delegated access.
- Keep tool catalogs smaller at the entry point. Plan for progressive discovery.
- Upgrade SDKs and run conformance tests as they mature.
The roadmap also changes how SEP proposals should be framed. If your proposal fits one of these five priority areas, it has a better chance of maintainer attention. If it does not, the burden is higher.
Why This Roadmap Matters
MCP is past the first wave of excitement. The next phase is less about whether agents can call tools and more about whether those calls can be secure, observable, scalable, and useful inside real workflows.
The new roadmap is a sign that the maintainers understand that shift. Agent identity, messaging, transport consistency, discovery, and SDK quality are not side quests. They are the pieces that let MCP move from demo integrations to infrastructure.
FAQ
Q: Does this roadmap replace the 2026-07-28 MCP specification?
A: No. The roadmap points to future work. The 2026-07-28 spec is the current protocol baseline.
Q: Should new MCP servers still support stdio? A: Yes, especially for local developer tools. But remote and production-facing servers should plan around Streamable HTTP.
Q: What is the biggest change for enterprise MCP adoption? A: Agent identity. Enterprises need workload identity, delegated authorization, auditability, and short-lived credentials before they trust autonomous agents with sensitive systems.
Q: Where should developers contribute? A: The roadmap points contributors toward working groups, SEP proposals, experimental extensions, SDK work, and conformance testing. Start with the priority area closest to the problem your server or client already solves.