In November 2024, Anthropic released the Model Context Protocol as a clean way to plug AI assistants into tools and data: one server, any compliant host, no bespoke integrations. Twenty months later, MCP has become the plumbing of the agent economy — reportedly 67 million monthly downloads of local MCP servers as of April 2026, and well over 10,000 public servers in the wild (figures from ecosystem analyses, not official tallies).

The July 2026 specification, revision 2026-07-28, is the protocol's biggest change since launch — and the updated roadmap that followed in August shows where the maintainers want to take it next. The short version: MCP is growing out of its "USB-C for chatbots" phase and into full agent infrastructure, with long-running work (Tasks), server-rendered interfaces (Apps), and a hardened, stateless core.

The headline: MCP goes stateless#

The most consequential change in 2026-07-28 is that MCP is now stateless at the protocol layer. The initialize/initialized handshake is gone (SEP-2575), and the Mcp-Session-Id header — the thing that pinned every client to whichever server instance issued it — is gone too (SEP-2567).

What that means in practice, per the official release notes: a remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer. Every request is self-contained: the protocol version travels in an MCP-Protocol-Version header and in _meta, and a new server/discover method lets clients learn a server's supported versions and capabilities before calling anything.

State doesn't disappear — it moves. Servers that need continuity across calls now mint explicit handles (a basket_id, a browser_id) and have the model pass them back as ordinary tool arguments. The maintainers argue this is actually an upgrade: the model can compose handles across tools and reason about them, rather than having session state hidden in transport metadata.

A few operational details matter for builders:

  • Routable traffic: the Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers, so load balancers and gateways can route on the operation without inspecting the body.
  • Cacheable lists: tools/list results carry ttlMs and cacheScope, modeled on HTTP Cache-Control — clients finally know how long a tool catalog is fresh.
  • Multi round-trip requests (MRTR, SEP-2322): server-initiated prompts like elicitation no longer hold an SSE stream open. The server returns an input_required result, the client gathers answers and retries with an opaque requestState, and any server instance can pick up the retry.
  • Deprecations: Roots, Sampling, and Logging are deprecated under a new feature-lifecycle policy that guarantees at least 12 months between deprecation and removal. HTTP+SSE transport is also on the way out.

The release also lifts tool schemas to full JSON Schema 2020-12 and documents W3C Trace Context propagation, so traces can follow a tool call from host through SDK to server into a single OpenTelemetry span tree.

Tasks graduates to an extension#

Long-running work has been the awkward hole in MCP: every tools/call was synchronous, so anything that took minutes meant timeouts, polling hacks, or abandoning the protocol.

Tasks arrived as an experimental core feature in the 2025-11-25 spec, but production use exposed enough redesign that the maintainers pulled them back out and reshaped them as an official extension — io.modelcontextprotocol/tasks (SEP-2663). The new lifecycle is built for the stateless model:

  • A server answers tools/call with a task handle instead of blocking.
  • The client drives it forward with tasks/get, tasks/update, and tasks/cancel.
  • Task creation is server-directed: the client advertises the extension, and the server decides when a call should run as a task.
  • tasks/list is removed entirely — it couldn't be scoped safely without sessions.

The migration note is blunt: if you shipped against the experimental 2025-11-25 Tasks API, you will need to migrate, because the extension lifecycle is not backward compatible.

Why this matters beyond protocol plumbing: Tasks are the primitive that lets agents do real asynchronous work — batch jobs, long computations, multi-step workflows — while the client moves on to other things. Combined with the new server-initiated events work on the roadmap (webhooks and channels, so clients stop polling), Tasks are how MCP stops being a request/response wrapper and starts being an agent coordination layer.

Apps: servers ship their own UI#

The other official extension in this release is MCP Apps (SEP-1865), the first official MCP extension of any kind. It lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe: a ui:// URI scheme for pre-declared UI resources, a _meta.ui.resourceUri link tying tools to the UI template that should render their results, and bi-directional JSON-RPC between the iframe and the host over postMessage.

Two design choices are worth noting. First, tools declare their UI templates ahead of time, so hosts can prefetch, cache, and security-review them before anything runs. Second, every UI-initiated action goes through the same audit and consent path as a direct tool call — the UI is a view onto MCP, not a side channel.

The host support is already broad: ecosystem trackers list Claude, VS Code Copilot, Microsoft 365 Copilot, Goose, and Postman among rendering clients, and OpenAI's ChatGPT Apps SDK is MCP-based, which means both major consumer agent platforms now speak some flavor of this standard. For developers, this collapses a category of work: configuration panels, dashboards, and rich result views can ship inside the server instead of as a separate web app.

The security angle is real — server-shipped HTML rendered inside your IDE is a new trust surface. The extension's answer is iframe sandboxing, declared content-security policies, and auditable messages; whether hosts enforce all of it consistently is the open question.

Governance and auth grow up#

Two institutional changes underpin all of this. First, MCP was donated to the Agentic AI Foundation under the Linux Foundation in December 2025, so the protocol is now community-governed rather than Anthropic-owned. Second, the release ships six authorization-hardening SEPs: RFC 9207 issuer validation, issuer-bound client credentials, application_type in dynamic client registration (so desktop and CLI clients stop being misclassified as web clients), plus a documented refresh-token flow and a clarified .well-known discovery suffix.

Governance also gets teeth: a formal deprecation lifecycle, an Extensions Track in the SEP process, and a conformance suite that Standards Track SEPs must satisfy before reaching Final.

The August roadmap: five priorities#

The updated roadmap, published in August 2026, organizes the next cycle into five priority areas:

Priority areaWhat it covers
Agentic messaging primitivesMaking Tasks, subscriptions/listen, and progress notifications work well together; server-initiated events (webhooks, channels) so clients stop polling; maturing the Tasks extension toward eventual spec inclusion
HTTP-native transport unificationExtending the stateless HTTP model to cover local servers too, unifying on one transport to simplify development
Agent identity & enterprise securityDPoP finalization, workload identity federation, an opinionated path for agent identity and delegation (agents acting as cloud workloads, on behalf of absent users, or delegating to sub-agents)
Improved primitivesOne clear contract for tools/call result handling; progressive tool discovery so a 100-tool server doesn't blow up the model's context before the user asks anything
SDK developer experienceErgonomics, spec conformance, and docs — especially since developers increasingly build MCP servers by pointing agents at the libraries

The thread connecting them: MCP is optimizing for a world where the callers are mostly agents, not people in browsers — progressive discovery, agent identity, and async messaging all answer that.

What builders should do now#

The takeaway for developers is straightforward:

  • Build new servers against 2026-07-28. Most pre-mid-2026 tutorials teach the handshake-based API that no longer exists; check the revision date on anything you read.
  • If you used experimental Tasks, migrate. The extension lifecycle isn't backward compatible — budget for it.
  • Adopt the explicit-handle pattern instead of reaching for session state; it's now the spec's answer to continuity across calls.
  • Consider whether your server needs a UI. With MCP Apps an official extension and major hosts rendering it, the question shifts from "should we build a companion web app?" to "why not ship the panel inside the server?"
  • Watch the five roadmap areas if you depend on MCP: agentic messaging and agent identity are where the next breaking-adjacent changes will come from, and SEPs inside these areas get expedited review.

MCP's second act isn't a new feature — it's a change of role. The protocol that connected chatbots to tools is being rebuilt as the coordination layer for an agent economy: stateless enough to scale like ordinary infrastructure, expressive enough to carry long-running work and rich UI, and governed enough to be trusted with enterprise workloads. The July spec poured the foundation; the roadmap says what gets built on it.

As of September 2026. Spec revision 2026-07-28 is the current stable release; the roadmap post is the maintainers' latest published direction.