MCP 2026 roadmap explained: what server builders should do now

The Model Context Protocol roadmap for 2026 was published on 9 March 2026 and named four priorities: transport evolution and scalability, agent communication, governance maturation, and enterprise readiness. Five months later, on 22 August 2026, the maintainers replaced that page with a new roadmap built around five priority areas, and the announcement post says the March priorities saw "significant progress in all of these over the past five months". This article keeps the March framing as a record of what was planned, and marks each pillar with what actually landed.

What changed between May and September 2026

Three dated events moved the ground under the original version of this article.

The practical summary: the March roadmap's transport pillar was not deferred, it was delivered, and it was more disruptive than the roadmap text suggested. Sessions did not get a migration story. They were removed.

What the March 2026 roadmap said

The roadmap was a priority document, not a release calendar. The maintainers had moved away from release-oriented planning toward priority areas, citing "uncertainty inherent in a fast-growing project". Four areas got expedited SEP review and the highest chance of acceptance. Everything outside them faced longer reviews and a higher justification bar. That mechanism survived the rewrite: the August 2026 roadmap keeps the same SEP prioritization rule, only the areas changed.

The four areas, and where each one ended up:

Transport scalability: what actually shipped

The March roadmap described three gaps in Streamable HTTP. Sessions were stateful, which conflicted with load balancers and horizontal scaling. There was no standard way to migrate a session across server restarts. And capability discovery required a live connection, which made registries and crawlers awkward.

The answer the Transports working group arrived at was not a session-resumption protocol. It was removing sessions. The 2026-07-28 changelog lists it as the first major change: protocol-level sessions and the Mcp-Session-Id header are removed from Streamable HTTP, list endpoints no longer vary per connection, and "servers that need cross-call state use explicit, server-minted handles passed as ordinary tool arguments" (SEP-2567). SEP-2575 removed the handshake itself and moved the protocol version and client capabilities into per-request _meta.

Capability discovery was solved in-protocol rather than out of band. Servers MUST implement server/discover, a single RPC returning supported protocol versions, capabilities, and identity. Calling it is optional for clients, which may send any request directly and handle an UnsupportedProtocolVersionError (code -32022).

The Server Card work is a separate story and it did not land. SEP-2127 defines an MCP Server Card served from /.well-known/mcp/server-card.json, and it is still a draft in an experimental extension repository rather than part of the 2026-07-28 specification. The Server Card working group charter lists a lead term ending 14 August 2026, and the August 2026 roadmap does not name the group among its priority areas. Publishing a Server Card today is a reasonable bet on where discovery is heading, but it is not a spec requirement and server/discover is the mechanism the specification actually mandates.

What did not change: no new official transport arrived. The August 2026 roadmap goes in the opposite direction and targets one transport model, with Streamable HTTP spoken over stdin and stdout for local servers, using HTTP/2 to get multiplexing while keeping the lifecycle guarantees of a subprocess.

Agent communication: Tasks moved out of the core protocol

The March roadmap framed this pillar as closing two lifecycle gaps in the Tasks primitive: retry semantics and expiry policies. The outcome was structural rather than incremental. In 2026-07-28, experimental tasks moved out of the core protocol and into an official extension, io.modelcontextprotocol/tasks, under SEP-2663. The redesign replaced the blocking tasks/result method with polling via tasks/get, added tasks/update for client-to-server input, removed tasks/list, and allowed servers to return task handles unsolicited without per-request opt-in.

Server-initiated requests were also reworked. The multi round-trip requests pattern (SEP-2322) replaces roots/list, sampling/createMessage, and elicitation/create as server-initiated calls. A server returns a result with resultType: "input_required" carrying the requests it needs answered, and the client retries the original request with the answers attached. Every result now carries a required resultType field, and clients must treat a missing one as "complete" for backward compatibility.

The May version of this article noted that triggers and server-initiated callbacks sat under "On the horizon" with no working group assigned, and advised treating event-driven behavior as a custom extension. That is now out of date. The August 2026 roadmap names a Triggers and Events working group and puts server-initiated events, including webhooks, in the first priority area, alongside a composition review across the Agents, Transports, and Triggers and Events groups to make sure Tasks, subscriptions/listen, and progress notifications share a lifecycle rather than offering three unrelated answers to "the server is not done yet".

The intersection with Google's A2A protocol remains narrow. A2A handles agent-to-agent message passing across organizational boundaries; MCP Tasks handle a single agent calling a tool that runs longer than a request. They compose, they do not replace each other.

Governance maturation: delivered, and retired as a priority

MCP graduated to the Linux Foundation under the Agentic AI Foundation in December 2025, with Anthropic, OpenAI, and Block as co-founders. SEP-1302 formalized Working Groups and Interest Groups. SEP-2085 established succession and amendment procedures. The March roadmap targeted the next bottleneck: every SEP required full Core Maintainer review regardless of domain.

That work landed. A Contributor Ladder now exists as the canonical definition of each role, its requirements, advancement process, and inactivity policy, and the governance page defers to it instead of restating role definitions. Working group charters are published under docs/community/ with scope, leadership, deliverables, and term dates, and working groups now provide quarterly updates at the end of January, April, July, and October. The 2026-07-28 revision also adopted a feature lifecycle and deprecation policy (SEP-2596) with a minimum twelve-month deprecation window and a public registry of deprecated features. Governance maturation does not appear as a priority area in the August 2026 roadmap, which is what delivery looks like on a priority document.

The advice from May holds. If your work touches a priority area, discuss your SEP in the relevant working group before opening a PR and bring the group's backing with you. SEPs with working group support move fastest. Only the list of priority areas changed.

Enterprise readiness became agent identity

The March roadmap called this the least-defined pillar and noted there was no Enterprise working group yet. The August 2026 roadmap renamed and sharpened it into "agent identity and enterprise-ready security", led by Paul Carleton and Den Delimarsky, with an Agent Identity working group forming during the period.

The framing is more specific than the original four bullet points. MCP authorization assumed a person with a browser at consent time, and increasingly the caller is a cloud workload with its own identity, acting for an absent user, or spawning sub-agents that should get narrower authority than their parent. The named deliverables are finalizing DPoP and driving its adoption, and an opinionated path for servers reached through an agent's own identity or a user-delegated identity, built on Workload Identity Federation (SEP-1933), the Identity Assertion JWT Authorization Grant used by the Enterprise-Managed Authorization extension, and RFC 8693 token exchange, coordinated with the IETF OAuth and WIMSE working groups.

Some enterprise-shaped hardening shipped in 2026-07-28 already. Authorization servers should include the iss parameter per RFC 9207 and clients must validate it (SEP-2468). Dynamic Client Registration now requires an application_type (SEP-837) and is itself deprecated in favor of Client ID Metadata Documents. Client credentials are bound to the issuer that minted them (SEP-2352). The March prediction that "much of the output will likely land as extensions rather than core specification changes" held: Enterprise-Managed Authorization is an extension.

The August 2026 roadmap, in one table

The current priority areas, as published on 22 August 2026:

One item there is worth reading twice if you maintain a server. Under improved primitives, the maintainers say tools/call allowing both content and structuredContent at the same time "has confused server and client authors alike and produced diverging implementations", and they intend to redesign that interface this period. The advice below about outputSchema and structuredContent is correct for the current revision, and it is also the part of the tool contract most likely to move next.

What MCP server builders should do today

Start today:

• Hold no state between requests. Servers MUST NOT rely on prior requests over the same connection to establish capabilities, protocol version, or client identity. If a handler reads anything that used to be set during initialize, that code has no future.
• Return a server-minted handle for anything large. The specification says state spanning multiple requests must be referenced by an explicit identifier the client passes on each request. For a PDF server that means returning a signed URL rather than a base64 payload.
• Register every tool with an outputSchema and return structuredContent. Still correct under 2026-07-28, with the caveat above that the result shape is on the current roadmap.
• Use structured error envelopes with a stable shape: error.type, error.code, error.message. This avoids forcing the agent to scrape natural-language errors.
• Expose resources and prompts, not just tools. Resources let the agent pull in your docs without a tool call. Prompts give the agent a starting point you control.
• Carry auth through AsyncLocalStorage or your runtime's equivalent context instead of threading the bearer token through every handler signature. Per-request auth is now the only shape that matches the protocol.
• Add MCP annotations to every tool: readOnlyHint, destructiveHint, idempotentHint, openWorldHint.
• Plan for server/discover, which servers must implement under the current revision. If you are on a handler library, this arrives when the library ships modern-era support.

Stop today:

• Stop holding sessions. Not just session IDs in URLs, which the 2025 retrospective from Pento already called out as a security problem: the session concept itself is gone from the protocol.
• Stop waiting for a session-resumption protocol. It is not coming. SSE stream resumability was removed along with Last-Event-ID, and a broken stream means re-issuing the request with a new request ID.
• Stop assuming a single server instance. Statelessness only buys horizontal scaling if the storage behind your handles moves off local disk too.
• Stop relying on "no auth at all" as the default. The Pento retrospective noted that many implementations defaulted to no auth. The agent identity priority makes that posture untenable for any non-toy server.
• Stop scraping tool output as plain text. If a client needs a structured field, give it structuredContent.
• Stop adding Roots, Sampling, or Logging to new implementations. All three are deprecated as of 2026-07-28, with a minimum twelve-month window before they become eligible for removal.

Here is the canonical shape of a tool registration with outputSchema and a structured-result helper, the pattern we use in our own handler:

import { z } from "zod";
 
server.registerTool(
  "list_templates",
  {
    description: "List the templates available to the authenticated user.",
    inputSchema: {
      api_key: z.string().optional(),
    },
    outputSchema: {
      templates: z.array(templateSummarySchema),
    },
    annotations: {
      readOnlyHint: true,
      destructiveHint: false,
      idempotentHint: true,
    },
  },
  async ({ api_key }) => {
    const auth = await resolveAuth(api_key);
    if (!auth) return authError();
    const templates = listTemplates(auth.organizationId);
    return structuredResult({ templates });
  }
);

Two details matter. First, the outputSchema lives next to the tool definition, so the client receives a typed structuredContent payload instead of a JSON-encoded text block it has to parse. Second, authError() returns a structured envelope (error.type, error.code, error.message) with isError: true, matching the shape the REST API uses. Sharing helpers across success and error paths keeps tool code DRY and makes the error contract auditable.

How PDF4.dev's MCP server aligns, as of September 2026

Our MCP server does not speak 2026-07-28 yet. It runs on mcp-handler 1.0.x over Streamable HTTP with SSE disabled, which means the legacy handshake and session model. Migration depends on the handler library shipping modern-era support rather than on our tool code. The full accounting is in the stateless spec article.

What lines up with the current revision:

• 14 tools, all registered via server.registerTool (not the deprecated server.tool) so each one carries an outputSchema. Shared Zod shapes keep structured content consistent across tools.
• Every tool returns through structuredResult(). The single exception is preview_template, which returns MCP image content instead of JSON.
• Every tool carries MCP annotations, so a host can warn the user before any write or render call.
• Errors are structured. authError(), permissionError(), notFoundError(), invalidRequestError(), and apiError() all return the same envelope with isError: true, so a client parsing a failure does not depend on conversation context.
• Auth is read from the request bearer token and carried to handlers through AsyncLocalStorage. No auth state is negotiated once and held between calls.
• render_pdf supports delivery: "url", returning a signed reference with a self-contained expiry rather than a base64 payload. That is the handle shape the current revision asks for, even though our URL is fetched over plain HTTP rather than passed back into MCP.
• Four resources under pdf4dev://docs/... and three prompts with Zod argument schemas.
• We publish a Server Card at /.well-known/mcp/server-card.json, an Agent Skills index, and an API Catalog. The Server Card remains a bet on a draft SEP rather than a spec requirement.

What does not line up yet: no server/discover implementation, because the handler library owns the protocol layer; no Tasks extension support; and render bytes still live on a single instance's disk, so horizontal scaling needs an object-storage swap before statelessness buys anything real.

What to watch next

• The Triggers and Events working group output on channels, subscriptions, and webhook delivery, and the cross-group composition review that has to make it fit with Tasks.
• HTTP over stdio from the Transports working group. If it lands, the stdio and HTTP split in every SDK collapses into one pipeline.
• The tools/call result shape redesign from the Core Primitives working group. This is the one that touches every existing tool handler.
• The Agent Identity working group forming, and whether DPoP adoption follows the specification.
• Whether the Server Card draft (SEP-2127) finds a home now that server/discover covers in-protocol capability discovery.

If you maintain an MCP server, the practical advice has not changed shape since May: align with the priority areas, follow the patterns above, and watch the working group channels rather than the release notes. What changed is the list, and the fact that the protocol underneath it is now stateless.

Sources:

• Roadmap (modelcontextprotocol.io/development/roadmap, last updated 2026-08-22)
• The new MCP roadmap (blog.modelcontextprotocol.io, 22 August 2026)
• Key changes in the 2026-07-28 revision (modelcontextprotocol.io)
• Versioning and feature states (modelcontextprotocol.io)
• Governance and stewardship (modelcontextprotocol.io)
• Working and Interest Groups (modelcontextprotocol.io)
• Server Card working group charter (modelcontextprotocol.io)
• The 2026 MCP Roadmap (blog.modelcontextprotocol.io, 9 March 2026)
• Maintainer team expansion (blog.modelcontextprotocol.io, 8 April 2026)
• A year of MCP, 2025 review (Pento)