MCP Is Growing Up (Agentic AI Foundation analysis of 2026-07-28 spec)

What it claims

The 2026-07-28 MCP release candidate is a breaking release. The page says the RC opened a 10-week validation window for SDK maintainers and client implementers, with the final spec expected on July 28, 2026. Its practical argument is that state, capabilities and authorization become explicit, so ordinary HTTP infrastructure can run MCP servers. The cost is that tool authors carry more of the security burden.

How it works

Stateless requests. A call such as tools/call now carries the protocol version, client info and capabilities in each request. New Mcp-Method and Mcp-Name headers let gateways, load balancers and rate limiters route traffic without parsing the body. Any server instance can serve any request, so sticky sessions and shared session stores are no longer required.

Explicit handles. A server returns a handle such as {"basket_id": "bkt_123"}, and the model passes it back on later calls, for example {"basket_id": "bkt_123", "item_id": "sku_456"}.

Extension negotiation. Each extension gets a reverse-DNS identifier, its own ext-* repository, delegated maintainers and an independent version. Clients and servers declare support in an extensions map within their capabilities. If one side lacks an extension, the connection still works without that capability.

• MCP Apps. Servers ship HTML UIs that hosts render in sandboxed iframes. UI templates are declared in advance so hosts can prefetch, cache and security-review them. UI actions go back over JSON-RPC and follow the same audit and consent path as a direct tool call.
• Tasks. Only after the client advertises Tasks support can the server choose to turn a tools/call into a task.

flowchart TD
  A[Client advertises Tasks ext] --> B[tools/call]
  B --> C{Server decides}
  C -->|immediate| D[Normal result]
  C -->|long-running| E[Task handle]
  E --> F[tasks/get · tasks/update · tasks/cancel]

Listing tasks was removed. Without sessions, the server cannot safely scope which tasks belong to whom.

Deprecations. Roots, Sampling and Logging are deprecated by annotation only. They keep working in this release and in every spec version published within a year of it. Removing them requires a separate SEP. The page's list of replacements did not render, but its prose points to these substitutes:

• Roots → tool inputs, resource URIs and server configuration
• Logging → OpenTelemetry and existing observability tooling
• Sampling → provider model APIs. The author notes this can reduce portability and make cross-provider orchestration harder.

OAuth/OIDC. For the one-client-to-many-servers case, the RC adds or tightens these rules:

• Desktop and CLI clients register as what they are, with localhost redirect URIs supported.
• Clients must validate the issuer of each authorization response.
• Credentials are bound to the authorization server that issued them.
• Token refresh has clearer rules.

Tool schemas. Full JSON Schema 2020-12 is supported. Inputs must still have a type: "object" root, but can use composition, conditionals and $ref. Output schemas are unrestricted, and structuredContent can be any JSON value.

Governance. Features move through Active, Deprecated and Removed states, with at least 12 months between deprecation and the earliest possible removal. Standards Track SEPs need matching conformance-suite scenarios before they can reach Final.

How to use it

The author's migration checklist:

1. Confirm requests can land on different server instances without losing context. Any failure points to a hidden session dependency.
2. Find everything your server remembers between calls, such as a repo path, browser session, task or deployment environment. Turn each into a handle the client can see, log and return.
3. Inventory your uses of Roots, Sampling and Logging and plan a migration for each.
4. Check issuer validation, credential binding, token refresh and OpenTelemetry tracing.
5. Tighten tool schemas while capping the cost of validating them.

Limits

• Handles move risk rather than removing it. Handles must be scoped, validated and expired. An unscoped basket_id or browser_id becomes a bearer token with unlimited power.
• Schemas need limits. The RC itself warns against blindly following external schema references and asks implementers to bound validation work.
• No list operation for tasks. Clients must track task handles themselves.
• RC, not final. The page describes the release candidate. Check the published 2026-07-28 spec for any changes made during the validation window.
• Advocacy source. The author is VP of the Agentic AI Foundation and the piece is commentary, not the spec text. It contains no migration effort figures or benchmarks.