MCP just got its biggest update ever - here’s what changes for AI agents

The Model Context Protocol gets its biggest update

The Model Context Protocol (MCP), the open standard that has quietly become the connective tissue between AI agents and the world's software, is getting its largest update since Anthropic released it twenty months ago - a sweeping architectural revision that its maintainers and backers say finally makes agentic AI ready for massive enterprise production deployments.

The update, released today under the stewardship of the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, finalizes MCP's transition to a fully stateless architecture, hardens its authentication model against a known class of attacks, establishes a formal 12-month deprecation policy, and graduates two headline capabilities - interactive server-rendered interfaces and long-running asynchronous tasks - into official protocol extensions.

The changes may sound arcane. Their consequences are anything but. According to the announcement, running MCP at scale has historically required "sticky routing" or shared state to maintain continuity across sessions - an operational burden that made large production deployments complex even when the underlying capabilities were simple. The new release removes that bottleneck entirely, letting organizations run MCP servers behind standard load balancers using the Kubernetes and cloud-native DevOps tooling they already operate.

"Some people jokingly call it a v2, and I think in spirit that's accurate," David Soria Parra, MCP's co-creator and a lead maintainer at Anthropic, told VentureBeat in an exclusive interview. "It's probably the biggest change we've ever made to the protocol, and with that, it's a big step up in maturing it for use by really big players."

Why stateless architecture is the key to running AI agents at enterprise scale

To understand why the industry's largest companies pushed for this release, it helps to understand what was broken. Under the old design, an MCP client - the AI application making requests - had to maintain a persistent session with a specific server instance. In modern cloud environments, where fleets of interchangeable compute nodes spin up and down behind load balancers, that requirement was poison. If the specific server holding your session state disappeared, your agent's work disappeared with it.

"Before, you needed to have a session store and manage session IDs - and if one of your compute pods went down, all of a sudden the requests would start failing," said Den Delimarsky, a lead maintainer of the protocol, in an interview with VentureBeat. "That's not going to be a problem with the new version of the protocol. That's a huge unlock, and it's one we collaborated with folks across many companies to put together."

Mazin Gilbert, executive director of the AAIF and a veteran of Google and AT&T, framed the change in historical terms - comparing it to the architectural decision that made the web itself possible.

"That stateless capability enables your MCP client to speak to a load balancer that connects with any server. You don't need the stickiness," Gilbert told VentureBeat. "You could not have the internet we have today if my browser couldn't speak to any website - with any server supporting that connection. You can switch between servers behind a load balancer."

Gilbert said the constraint had become the primary blocker for companies trying to move AI agents from pilots into production.

"I've come across companies who are deploying tens of thousands of agents, and you cannot do that without having to go in this direction," he said.

Crucially, he argued, the obstacle was never the AI itself: "It wasn't the technology, it wasn't the business case, it was really these fundamental changes that were required."

The tension is nearly as old as the protocol. A public design discussion opened by MCP co-creator Justin Spahr-Summers on GitHub in December 2024 - just weeks after launch - flagged that MCP's long-lived, stateful connections were limiting for serverless deployments, and sketched three possible paths forward, including the fully stateless option the protocol has now largely embraced. Engineers from Vercel, Cloudflare, Shopify, and Amazon weighed in over the following months, a preview of the multi-vendor collaboration that would eventually define the project. The core maintainers formally committed to the direction at a December 2025 meeting on the future of MCP transports, according to the announcement.

The trade-offs of removing state from the Model Context Protocol

Protocol design is a game of trade-offs, and the maintainers were unusually candid about what this one cost.

First, payloads get bigger.

"A lot of the state doesn't disappear, but it's moved back and forth with the server on the wire, at the actual transport layer," Soria Parra explained. "You get bigger payloads in return for statelessness - but luckily they're very compressible and very well understood, and still fairly small in comparison to an HTTP request on the web."

Second, a handful of rarely used capabilities are gone or narrowed. Out-of-band server logging - where a server could push informational log messages to a client at any moment - no longer works in the new model. The team did its homework before cutting it: "As part of the whole exercise, we scraped all of GitHub and looked at who is using it - and it's basically nobody," Soria Parra said. Those affected amount to "probably a handful of people - quite literally a handful of people." He even allowed himself a moment of engineering self-deprecation.

"I'm sad that things I thought were useful turned out not to be useful," he said. "I think one of the bigger trade-offs was more about my ego than any actual limitation of the protocol."

Delimarsky argued the shift is less a removal of state than a deliberate transfer of responsibility.

"With statelessness, we did shift the responsibility of creating and managing state to the developers - but very intentionally so," he said. Under the old protocol, "a lot of folks had a hard time understanding: Do I need to use this? Where do I use this? How do I use this? Removing that burden basically says: look, now you can manage state in the way that makes sense for your environment."

For most developers, migration should be nearly painless, because the vast majority of the ecosystem builds on official SDKs in TypeScript, Python, C#, Rust, Java, and other languages, which will absorb the changes.

"One of the key things we constantly do is double-check that the upgrade path is minimal - to the point where any model in the world will probably one-shot it for you," Soria Parra said - a telling remark in itself, reflecting an era in which protocol maintainers now design migrations to be trivially executable by AI coding assistants.

How a 12-month deprecation policy gives enterprises the stability guarantee they demanded

Perhaps the most enterprise-flavored feature of the release isn't code at all. It's a policy. The new formal deprecation framework guarantees developers a minimum of twelve months between a feature's formal deprecation and its earliest possible removal - the kind of stability contract that lets a Fortune 500 engineering organization commit to a specification without fearing silent breakage.

The number wasn't picked arbitrarily. "We consulted with folks like Google, Microsoft, and Amazon to find out: in your deployment environment, what's the right path for making these kinds of changes?" Delimarsky said. "Twelve months seemed like the reasonable middle ground."

He stressed that features are not being torn out on a whim: "It's not about ripping stuff out of the protocol just because we don't like it. There's a very, very strong industry pull behind these changes."

Soria Parra added that the maintainers' own telemetry supports the figure - most of the ecosystem upgrades within six to eight months - and stressed that the window functions more as a listening period than a countdown clock.

"It just says that in 12 months we are open to remove it, but both Den and I can change our minds based on feedback," he said. "I think it's more of a feedback period than a definite period."

Gilbert sees the policy as one leg of a three-legged stool of enterprise trust, alongside open standards and stateless scale.

"There are companies deploying things at a smaller scale, but they're slowed down because of MCP's authorization gap, because of identity, because of - do they trust the deprecation policy? Things could change basically any day," he said. Those companies, he argued, "are going to benefit not because of the statelessness. They're going to benefit because of the security."

New authentication hardening closes OAuth mix-up attacks before hackers could exploit them

The release also ships significant authorization hardening, aligning MCP's auth specification with how OAuth 2.0 and OpenID Connect are actually deployed in practice. Most notably, the protocol now enforces mandatory validation of the issuer (iss) parameter - a protocol-level defense that, according to the announcement, closes an entire class of so-called mix-up attacks, in which a client can be tricked into associating an authorization response with the wrong identity server.

Was anyone actually attacked? No, Delimarsky said - this was preventive engineering, not incident response.

"This is not something that is gated in any existing vulnerabilities or active exploitation," he said. "This is more of us engaging directly with the security community."

The philosophy, he explained, is to borrow rather than invent: "MCP as a protocol is very much establishing the pattern of: we do not want to reinvent the wheel, but we also want to be at the forefront of a lot of the security innovation."

That posture is most visible in the new Enterprise Managed Authorization extension, developed in close collaboration with identity provider Okta, which lets organizations make their corporate identity provider the authoritative gatekeeper for MCP server access.

"If I'm somebody that manages tens, hundreds of MCP servers for my organization, I want to make sure that I enforce some level of common governance, where folks auth with their corporate credentials and not their personal credentials, so that the client doesn't send data to sources that are unauthorized," Delimarsky said. Okta bootstrapped the underlying open standard, he noted, and the maintainers then worked "to make sure that it's adopted ecosystem-wide, and it's not something that is specific to only one vendor or provider."

More is coming: Delimarsky said proposals are already on deck for demonstrated proof-of-possession and workload identity federation - capabilities requested by security teams running MCP in production.

Gilbert connected the work to a broader maturation: "MCP has now bridged that gap with these authorization protocols, so it's basically now becoming what we call enterprise ready, versus an open lab sort of experiment."

MCP Apps and Tasks become official extensions, pushing AI agents beyond text responses

Two capabilities graduate to official extension status in this release, taking advantage of a new framework that lets extensions evolve on their own timelines, independent of the core specification - a structural choice that lets the protocol grow without bloating its core.

MCP Apps allows servers to ship rich, interactive, server-rendered user interfaces directly into AI clients - moving agent output beyond walls of text toward dashboards, forms, and visualizations, and dramatically accelerating development of user-facing agentic applications, according to the announcement.

MCP Tasks tackles the reality that not every tool call finishes in one round trip. Instead of holding fragile, long-lived connections open while a batch job or heavy computation grinds away, servers now return a durable task handle; clients can disconnect, crash, restart, and resume polling.

"You've been processing some audio for a podcast or a video - it can notify back the client and say, hey, the task is done. You don't need to wait and keep the stream open," Delimarsky said.

A third addition, multi-round-trip requests, lets servers and clients negotiate back and forth within a single logical operation. "It's not just a one-shot - over the stream, get the input and you're done," Delimarsky said. "You can actually interact, server to client, to get the right parameters to execute an action."

Soria Parra emphasized that these capabilities emerged from the same source as the architectural overhaul: heavyweight production users.

"This is a version that came together by some of the best distributed systems experts at Microsoft, Google, and others coming together and working on this for their specific needs - and the needs of the industry at large," he said.

How independent is MCP from Anthropic under Linux Foundation governance?

Anthropic created MCP in November 2024 and donated it to the newly formed AAIF under the Linux Foundation in December 2025, alongside founding projects from Block and OpenAI. Seven months later, the independence question still hangs over the project - and both sides addressed it head-on.

Soria Parra was disarmingly direct about the residual power he holds. As lead maintainer and Anthropic employee, "I do have veto rights, technically," he acknowledged - "but I think we have never actively used it in any kind of discussion."

The core maintainer group now spans Anthropic, Microsoft, OpenAI, Google, and Amazon, with contributions from companies like Block, and key decisions "are usually unanimous," he said. "Technically we have a lot of influence; de facto, we're not exerting any of it." He added that governance will progressively broaden: "As the project progresses, we will increasingly move to more different governing structures that include more and more people."

Gilbert, who has helped stand up multiple foundations during his time working with the Linux Foundation, offered the numbers backing the project's momentum: tens of millions of dollars in funding and scores of companies.