7 MCP changes for agent builders

This release candidate makes MCP easier to run, inspect, secure, and extend for agent builders.

The 2026-07-28 MCP release candidate adds clearer state, tighter auth, and more structured extensions, giving teams a better base for agentic systems.

Item	What changed	Why it matters
Stateless protocol	Request carries version, client info, capabilities	Better routing and scaling
Explicit state handles	Handles like basket_id move into tool outputs	More visible workflow state
Extensions	Reverse-DNS IDs, versioned repos, negotiation	Cleaner feature growth
Tasks	task/get, task/update, task/cancel	Long jobs fit the protocol
Auth updates	Sharper OAuth/OIDC rules	Safer multi-server deployments
JSON Schema 2020-12	Composition, conditionals, references	More accurate tool contracts
Governance policy	Active, Deprecated, Removed states	Less churn, clearer upgrades

1. Stateless protocol requests

MCP is moving the protocol layer toward stateless requests, which makes it easier to run behind load balancers, gateways, and rate limiters. Instead of depending on a session that has to be preserved across calls, a request can carry the information the server needs right away.

That shift matters because it makes MCP behave more like ordinary HTTP services. Teams can route, scale, and debug remote servers without special session plumbing getting in the way. The release candidate even uses headers such as Mcp-Method and Mcp-Name so infrastructure can make routing decisions without inspecting the body.

• Self-contained calls such as tools/call
• No sticky-session requirement at the protocol layer
• Better fit for distributed infrastructure

2. Explicit state handles

Stateless protocol design does not remove application state, it just moves it into a place the agent can see. A tool can return a handle, such as basket_id or browser_id, and later calls can reuse that value directly.

That makes workflows easier to reason about because the model can carry the handle from step to step instead of relying on hidden session metadata. It also improves logging and orchestration, since the client and server can record the same visible identifier across the whole flow.

• Visible identifiers like basket_id
• Tool outputs can feed later tool calls
• Handles still need scoping, validation, and expiry

3. Structured extensions

Extensions now have a more formal home in MCP, with reverse-DNS identifiers, versioned extension repositories, delegated maintainers, and capability negotiation. That gives implementers a cleaner path for features that are useful, but not ready to sit in the core spec forever.

The first big examples are MCP Apps and Tasks. MCP Apps can ship interactive HTML that hosts render in sandboxed iframes, while Tasks lets servers turn long-running work into handles that clients can query, update, or cancel later.

• Extension IDs use reverse-DNS naming
• Clients and servers advertise support through capability maps
• Tasks supports tasks/get, tasks/update, and tasks/cancel

4. Deprecations with a policy

Roots, Sampling, and Logging are deprecated under the new feature lifecycle policy, which is a strong signal about where MCP wants to focus. The spec is narrowing its scope to the client-server contract and leaving adjacent concerns to systems that already handle them well.

That means workspace boundaries can often move into tool inputs, resource URIs, or server config, while observability can go to stderr or OpenTelemetry. The deprecations are annotation-only for now, and removal needs a separate SEP, so teams get time to adapt instead of being forced into a fast rewrite.

• Roots shifts toward tool parameters or resource URIs
• Sampling shifts toward provider APIs
• Logging shifts toward stderr and OpenTelemetry

5. Stronger authorization rules

The release candidate tightens OAuth and OpenID Connect details for the common case where one client talks to many MCP servers. That includes clearer rules for issuer validation, credential binding, localhost redirect support, and how desktop or CLI clients should register.

These changes sound small, but they help prevent confusing failures and unsafe auth behavior in real deployments. For agent systems that touch private data, paid services, or user-specific workflows, clearer authorization is not optional housekeeping, it is part of the product.

Client -> Authorization Server -> MCP Server validate issuer bind credentials to issuing server support localhost redirects for desktop and CLI apps

6. Full JSON Schema support

MCP tool schemas now support full JSON Schema 2020-12, which makes tool contracts more accurate. Inputs still require an object root, but authors can use composition, conditionals, and references to describe real-world shapes more precisely.

That helps when a tool has optional paths, conditional fields, or outputs that do not fit neatly into one static object. The spec also warns implementers not to follow external references blindly and to limit validation work, which is the right caution for a more expressive schema system.

• Composition and conditionals are allowed
• Output schemas are unrestricted
• Validation needs guardrails for performance and safety

7. Governance that can absorb change

The release candidate adds governance pieces that make future changes easier to manage. The feature lifecycle policy defines Active, Deprecated, and Removed states, with at least 12 months between deprecation and the earliest removal.

It also asks Standards Track SEPs to have matching scenarios in the conformance suite before Final status. That gives SDKs, servers, and clients a shared target, which reduces interpretation drift and keeps the spec more usable as it grows.

What to pick

If you run MCP infrastructure, start with the stateless protocol changes and the auth updates. If you build tools or agent workflows, focus on explicit state handles, Tasks, and JSON Schema support. If you maintain a platform or SDK, the extension framework and governance policy are the parts that will shape your roadmap.

For most teams, the best next step is to treat this release candidate as a prompt to simplify hidden state, tighten authorization, and move long-running or optional features into explicit extensions.