{"slug": "mcp-is-growing-up", "title": "MCP Is Growing Up", "summary": "The 2026-07-28 release candidate for the Model Context Protocol (MCP) makes the protocol stateless, requiring each request to carry its own protocol version, client info, and capabilities rather than relying on session IDs. This shift eliminates the need for sticky sessions and special gateway routing, making MCP servers easier to scale and debug like standard web services. The update also moves application state into explicit handles that models can pass between tool calls, improving agent reasoning and workflow observability.", "body_md": "*The 2026-07-28 release candidate makes MCP easier to run, reason about, and extend in agentic systems.*\n\nThe 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.\n\nA lot of protocol releases only matter if you’re deep in implementation details.\n\nThis one is different.\n\n[The 2026-07-28 MCP release candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-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.\n\nThere are breaking changes, so implementers have work to do. But the direction is healthy.\n\nThe 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.\n\nThat 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.\n\n## MCP needed to get easier to operate\n\nThe biggest technical change is that MCP is becoming stateless at the protocol layer.\n\nIn previous MCP versions, a Streamable HTTP client established a session first. The server returned an `Mcp-Session-Id`\n\n, 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.\n\nThat’s manageable during experimentation, but it gets painful when you’re running remote MCP servers behind load balancers, gateways, and rate limiters.\n\nWith the release candidate, a request like `tools/call`\n\ncan be self-contained. The protocol version, client info, and capabilities travel with the request. Headers like `Mcp-Method`\n\nand `Mcp-Name`\n\nlet infrastructure route traffic without inspecting the body.\n\nThat 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.\n\nThat’s a practical win. If a protocol requires special infrastructure too early, teams either avoid it or build fragile workarounds around it.\n\n## Stateless doesn’t mean state disappears\n\nOne part of this release that I find especially interesting is the distinction between protocol state and application state.\n\nMCP 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.\n\nThe difference is that the state becomes explicit.\n\nInstead of hiding state in transport metadata, the server can return a handle and the model can pass that handle back in later tool calls.\n\nFor example, a tool might create a basket and return this:\n\n```\n{\n  \"basket_id\": \"bkt_123\n}\n```\n\nA later call can use it directly:\n\n```\n{\n  \"basket_id\": \"bkt_123\",\n  \"item_id\": \"sku_456\"\n}\n```\n\nThat may look small, but it’s meaningful for agents.\n\nWhen 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.\n\nThe visible state improves reasoning, observable workflows improve orchestration, and explicit handles give agents something concrete to coordinate around.\n\nBe careful, though. This design puts more responsibility on tool authors.\n\nA handle should be scoped, validated, and expired appropriately. If `basket_id`\n\nor `browser_id`\n\nbecomes a magic token with unlimited power, you’ve moved the risk from one layer to another.\n\nExplicit state is easier to inspect, but it still needs good security and lifecycle design.\n\n## Extensions get a real process\n\nExtensions already existed in MCP, but they didn’t yet have much structure around them.\n\nThis release changes that. Extensions now have reverse-DNS identifiers, their own `ext-*`\n\nrepositories, 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.\n\nThis is great for people building integrations.\n\nA 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.\n\nMCP Apps and Tasks are the first clear examples.\n\nMCP 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.\n\nTasks handles long-running work. A server can return a task handle from `tools/call`\n\n, and the client can later use `tasks/get`\n\n, `tasks/update`\n\n, or `tasks/cancel`\n\n. 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.\n\nWith this update, `tasks/lists`\n\nis 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.\n\nThe 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.\n\n## Deprecating Roots, Sampling, and Logging is a signal\n\nThe release candidate deprecates Roots, Sampling, and Logging under the new feature lifecycle policy.\n\nThat 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.\n\nThe replacements tell an interesting story:\n\n| Deprecated feature | Direction |\n| Roots | Tool parameters, resource URIs, or server configuration |\n| Sampling | Direct integration with LLM provider APIs |\n| Logging | stderr for stdio and OpenTelemetry for structured observability |\n\nI read this as MCP narrowing its responsibilities. That’s a good thing.\n\nMCP 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.\n\nWorkspace scoping can often be expressed more directly through tool inputs, resource URIs, and server configuration.\n\nObservability belongs with the tools teams already use to debug distributed systems.\n\nModel 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.\n\nIf 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.\n\nThe 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.\n\nThat’s also a good sign. Deprecation with a defined policy gives teams time to migrate.\n\n## Authorization is catching up to real deployment patterns\n\nAuthorization work usually doesn’t get the loudest applause, but it’s one of the most important parts of this release.\n\nMCP 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.\n\nThe 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.\n\nThe practical result is fewer assumptions.\n\nFor 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.\n\nFor 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.\n\n## Full JSON Schema makes tools more honest\n\nTool schemas are also getting more expressive with full JSON Schema 2020-12 support.\n\nInputs still keep the `type: \"object\"`\n\nroot constraint, but they can now use composition, conditionals, and references. Output schemas are unrestricted, and `structuredContent`\n\ncan be any JSON value.\n\nThat’s another practical improvement.\n\nReal 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.\n\nWatch 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.\n\nThat’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.\n\n## The protocol is building a governance muscle\n\nThe part I find most encouraging is the governance direction.\n\nThis release includes breaking changes, but it also introduces mechanisms to make breaking changes less common going forward. The feature lifecycle policy defines `Active`\n\n, `Deprecated`\n\n, and `Removed`\n\nstates with at least 12 months between deprecation and the earliest possible removal.\n\nThe 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`\n\nstatus.\n\nA 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.\n\nIt 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.\n\nThis 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.\n\nIt’s not glamorous work, but it’s the work that keeps an ecosystem open.\n\n## What I’d do next\n\nMCP is already carrying serious workloads, and the protocol is starting to reflect that reality. [The release candidate is available now](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/), 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.\n\nIf your agentic system depends on MCP servers, I wouldn’t treat this as a spec-reading exercise. Test the parts that may fail first.\n\nCan your requests move across server instances without losing important context? If they can’t, find the hidden session dependency now.\n\nLook 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.\n\nCheck 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.\n\nReview 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\n\nTool schemas deserve a pass too. Make them precise enough to guide clients, but don’t turn schema validation into a performance or security problem.\n\nThis release asks implementers to do real migration work. It also gives the ecosystem cleaner primitives that make future changes less surprising.\n\nNow is the time to test the release candidate against the messy parts of your implementation and bring those findings back to the [specification repo](https://github.com/modelcontextprotocol/modelcontextprotocol) and [Working Group discussions](https://discord.gg/6CSzBmMkjX).\n\nOpen protocols get stronger when the weird cases show up early.", "url": "https://wpnews.pro/news/mcp-is-growing-up", "canonical_source": "https://aaif.io/blog/mcp-is-growing-up/", "published_at": "2026-05-27 15:33:52+00:00", "updated_at": "2026-06-05 04:43:18.026965+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-tools", "large-language-models"], "entities": ["Model Context Protocol", "MCP"], "alternates": {"html": "https://wpnews.pro/news/mcp-is-growing-up", "markdown": "https://wpnews.pro/news/mcp-is-growing-up.md", "text": "https://wpnews.pro/news/mcp-is-growing-up.txt", "jsonld": "https://wpnews.pro/news/mcp-is-growing-up.jsonld"}}