MCP Is Growing Up

The 2026-07-28 release candidate makes MCP easier to run, reason about, and extend in agentic systems.

The next MCP specification release candidate is a big one. The headline change is that MCP is becoming stateless at the protocol layer, but the more useful story is what that does for people building agentic systems in practice.

A lot of protocol releases only matter if you’re deep in implementation details.

This one is different.

The 2026-07-28 MCP release candidate is worth paying attention to because it shows where the Model Context Protocol is heading. MCP started as a practical way to connect AI applications to tools, data, and services. That’s still the point. This release tightens the contract between clients and servers so those connections are easier to operate, observe, and evolve.

There are breaking changes, so implementers have work to do. But the direction is healthy.

The most interesting shift is that MCP is making important parts of agent workflows more explicit. State moves into visible handles. Capabilities move into negotiated extensions. Authorization rules get sharper. Observability moves toward the tools teams already use.

That may sound like plumbing, but good plumbing is what keeps agent systems from turning into a pile of clever demos that nobody wants to maintain.

MCP needed to get easier to operate

The biggest technical change is that MCP is becoming stateless at the protocol layer.

In previous MCP versions, a Streamable HTTP client established a session first. The server returned an Mcp-Session-Id, and the client carried that ID into later requests. That meant deployments had to care about sticky sessions, shared session stores, and gateway behavior that understood enough about MCP to route traffic correctly.

That’s manageable during experimentation, but it gets painful when you’re running remote MCP servers behind load balancers, gateways, and rate limiters.

With the release candidate, a request like tools/call can be self-contained. The protocol version, client info, and capabilities travel with the request. Headers like Mcp-Method and Mcp-Name let infrastructure route traffic without inspecting the body.

That gives teams more ordinary HTTP behavior. Each request carries what the server needs, so any available server instance can handle it. Scaling and debugging MCP servers starts to look more like scaling and debugging other web services.

That’s a practical win. If a protocol requires special infrastructure too early, teams either avoid it or build fragile workarounds around it.

Stateless doesn’t mean state disappears

One part of this release that I find especially interesting is the distinction between protocol state and application state.

MCP applications still need memory for real workflows. A server may need to know which repository an agent is analyzing or which browser session an automation tool is driving. With this update, that state is handled explicitly by the application instead of hidden inside the protocol session.

The difference is that the state becomes explicit.

Instead of hiding state in transport metadata, the server can return a handle and the model can pass that handle back in later tool calls.

For example, a tool might create a basket and return this:

{
  "basket_id": "bkt_123
}

A later call can use it directly:

{
  "basket_id": "bkt_123",
  "item_id": "sku_456"
}

That may look small, but it’s meaningful for agents.

When the model can see the handle, it can reason about it, pass it between steps, and explain what it’s doing. The client and server can log it as part of the workflow instead of treating it as hidden session plumbing.

The visible state improves reasoning, observable workflows improve orchestration, and explicit handles give agents something concrete to coordinate around.

Be careful, though. This design puts more responsibility on tool authors.

A handle should be scoped, validated, and expired appropriately. If basket_id or browser_id becomes a magic token with unlimited power, you’ve moved the risk from one layer to another.

Explicit state is easier to inspect, but it still needs good security and lifecycle design.

Extensions get a real process

Extensions already existed in MCP, but they didn’t yet have much structure around them.

This release changes that. Extensions now have reverse-DNS identifiers, their own ext-* repositories, delegated maintainers, and versions that can move independently from the main MCP specification. Clients and servers also negotiate support through an extensions map in their capabilities.

This is great for people building integrations.

A client shouldn’t have to guess whether a server supports MCP Apps or which version of Tasks it expects. The server should advertise what it supports. The client should do the same. If both sides support the same extension, they can use it. If they don’t, the connection can still work without that capability.

MCP Apps and Tasks are the first clear examples.

MCP Apps lets servers ship interactive HTML interfaces that hosts render in sandboxed iframes. Tools declare their UI templates ahead of time, so hosts can prefetch, cache, and security-review them before anything runs. The UI still talks back through MCP’s JSON-RPC protocol, so a button click in the app follows the same audit and consent path as a direct tool call.

Tasks handles long-running work. A server can return a task handle from tools/call, and the client can later use tasks/get, tasks/update, or tasks/cancel. Task creation is server-directed, meaning the server decides when a tool call should become a task after the client has advertised that it supports the extension.

With this update, tasks/lists is removed. Without sessions, listing tasks safely gets tricky because the server needs to know which tasks belong to which scope. Removing it is a good example of the spec choosing a safer design over a convenient one.

The important shift is that MCP now has a structured place for capabilities that are useful, but still need room to evolve. That keeps core MCP more focused while still letting the ecosystem experiment in a way implementers can actually build against.

Deprecating Roots, Sampling, and Logging is a signal

The release candidate deprecates Roots, Sampling, and Logging under the new feature lifecycle policy.

That might surprise people, especially Roots. Roots were one of the early concepts that helped define workspace boundaries. Sampling, one of my favorite features of the protocol, gave servers a way to request model completions through the client. Logging gave servers a protocol-level logging mechanism.

The replacements tell an interesting story:

I read this as MCP narrowing its responsibilities. That’s a good thing.

MCP is strongest when it defines the client-server contract clearly and leaves surrounding concerns to the systems that already handle them well. It should be cautious about becoming the owner of every concern near an agent.

Workspace scoping can often be expressed more directly through tool inputs, resource URIs, and server configuration.

Observability belongs with the tools teams already use to debug distributed systems.

Model access is often better handled through provider APIs that already own that surface area, though there is a real tradeoff there. Pushing model interaction outward can reduce portability in some environments and make cross-provider orchestration harder. The spec seems to be choosing operational clarity over trying to abstract every model interaction.

If MCP tries to own too much, it becomes harder to implement and harder to reason about. If it owns the right things well, the ecosystem around it can grow with less friction.

The deprecations are annotation-only for now. The methods and capability flags still work in this release and in every specification version published within a year of it. Removing them will require a separate SEP.

That’s also a good sign. Deprecation with a defined policy gives teams time to migrate.

Authorization is catching up to real deployment patterns

Authorization work usually doesn’t get the loudest applause, but it’s one of the most important parts of this release.

MCP has a deployment shape that can be tricky: one client may talk to many servers. That makes OAuth and OpenID Connect details matter a lot.

The release candidate tightens several OAuth and OpenID Connect details for the case where one client talks to many MCP servers. Clients need clearer rules for who issued an authorization response, what kind of application is registering, which authorization server credentials belong to, and how token refresh should work.

The practical result is fewer assumptions.

For example, desktop and CLI clients need to be registered in a way that matches how they actually run, including support for localhost redirect URIs. Clients also need to validate which issuer sent an authorization response and keep credentials tied to the authorization server that issued them. These details may seem small, but they prevent confusing failures and unsafe authorization behavior in real deployments.

For the broader agentic ecosystem, this is essential. Agents will increasingly touch private data, company systems, paid services, and user-specific workflows. Weak authorization semantics are not a small implementation detail in that world. They’re the difference between a useful agent and a security incident with a friendly chat interface.

Full JSON Schema makes tools more honest

Tool schemas are also getting more expressive with full JSON Schema 2020-12 support.

Inputs still keep the type: "object" root constraint, but they can now use composition, conditionals, and references. Output schemas are unrestricted, and structuredContent can be any JSON value.

That’s another practical improvement.

Real tools often have conditional shapes, optional paths, and outputs that don’t fit neatly into one object. Stronger schema support lets tool authors describe those requirements directly instead of burying them in the tool description.

Watch out for schema complexity, though. The release candidate also warns implementers not to blindly follow external schema references and to put limits on validation work.

That’s the right warning. A schema system powerful enough to describe real tools is also powerful enough to hurt performance or open unpleasant security problems if implemented casually.

The protocol is building a governance muscle

The part I find most encouraging is the governance direction.

This release includes breaking changes, but it also introduces mechanisms to make breaking changes less common going forward. The feature lifecycle policy defines Active, Deprecated, and Removed states with at least 12 months between deprecation and the earliest possible removal.

The Extensions framework gives experimental capabilities a place to mature outside core. Standards Track SEPs need matching scenarios in the conformance suite before they can reach Final status.

A spec without conformance tests leaves too much room for interpretation. SDKs, servers, and clients can each make slightly different assumptions, which makes compatibility harder over time. That’s how a standard can slowly become tied to the behavior of the largest implementation. Requiring conformance scenarios makes the protocol more concrete.

It also supports a healthier open ecosystem. If implementers can test against the same expectations, smaller projects have a better chance of being compatible. That reduces lock-in and makes MCP more useful as a shared standard rather than a branded integration format.

This is also why AAIF cares so much about neutral governance. Open protocols need real implementations, conformance work, and room for the community to challenge designs before they harden.

It’s not glamorous work, but it’s the work that keeps an ecosystem open.

What I’d do next

MCP is already carrying serious workloads, and the protocol is starting to reflect that reality.  The release candidate is available now, and the final specification is expected on July 28, 2026. The 10-week window is for SDK maintainers and client implementers to validate the changes against real workloads.

If your agentic system depends on MCP servers, I wouldn’t treat this as a spec-reading exercise. Test the parts that may fail first.

Can your requests move across server instances without losing important context? If they can’t, find the hidden session dependency now.

Look at every place your server remembers something between tool calls. A repository path, browser session, task, or deployment environment should have an explicit handle or scope that the client can see, log, and pass back safely.

Check your use of Roots, Sampling, and Logging. Deprecated doesn’t mean broken today, but it does mean you need a migration path. MCP servers are still distributed systems. Teams that forget that are going to have operational problems.

Review authorization and observability too. Issuer validation, credential binding, token refresh, and OpenTelemetry traces are not optional details once MCP servers are part of real deployments

Tool schemas deserve a pass too. Make them precise enough to guide clients, but don’t turn schema validation into a performance or security problem.

This release asks implementers to do real migration work. It also gives the ecosystem cleaner primitives that make future changes less surprising.

Now is the time to test the release candidate against the messy parts of your implementation and bring those findings back to the specification repo and Working Group discussions.

Open protocols get stronger when the weird cases show up early.