How MCP’s biggest update changes enterprise AI agent infrastructure

MCP’s biggest enterprise upgrade changes infrastructure

The Model Context Protocol’s biggest change since its creation reshapes the infrastructure around AI agents. MCP, the open standard Anthropic created in November 2024 to connect AI agents with software, is now roughly twenty months into a transition from an Anthropic project toward shared infrastructure. Its latest release changes assumptions about sessions, authorization, upgrades, and project control that had made the rapidly adopted protocol difficult to operate and trust at enterprise scale.

David Soria Parra, MCP co-creator, lead maintainer at Anthropic, Anthropic employee, and holder of a technical veto over the project, described the release’s scale in an interview with VentureBeat. Anthropic created MCP and benefits when its protocol becomes infrastructure used across the AI market, so its maintainers have a direct interest in wider adoption. “Some people jokingly call it a v2, and I think in spirit that’s accurate,” Soria Parra said. “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.”

The enterprise question also brought in perspectives beyond Anthropic. VentureBeat interviewed lead maintainer Den Delimarsky and Mazin Gilbert, executive director of the Agentic AI Foundation (AAIF), a Google and AT&T veteran who has experience creating foundations with the Linux Foundation. Gilbert leads the foundation that stewards MCP, so AAIF benefits institutionally as the protocol gains members, adoption, and influence. His test for enterprise trust has three conditions: an open standard, stateless scalability, and neutral governance, a combination he says was absent a year ago and even six months ago.

Those conditions turn protocol maturity into an infrastructure question. A company choosing a long-lived dependency needs interchangeable server instances, familiar identity and security controls, enough warning to manage incompatible changes, and governance that can earn trust across suppliers. “If I were a Fortune 500 company looking at how I trust the internet, I‘d need those three things to fall into place, and they were not in place a year ago. They were not in place even six months ago. But they are in place today,” Gilbert said. The release strengthens those areas, while state still exists, security work continues, and an Anthropic employee retains formal veto power.

Stateless transport changes the operating model

The first enterprise requirement appears in how an MCP request reaches a server. Previously, an MCP client established an ongoing session with a particular server instance, forcing infrastructure to preserve that relationship through sticky routing, meaning repeated requests were sent back to the same instance, or through shared storage for session information. Cloud-native fleets routinely replace compute instances while load balancers distribute requests across available capacity. Under the earlier design, losing the instance holding an MCP session could interrupt later requests and lose work associated with the agent.

Delimarsky described that failure mode at the compute-pod level. “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,” he said. “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.” Operators therefore had to preserve enough continuity for later requests to find state associated with the earlier interaction.

Stateless transport changes where that continuity lives. A request can now arrive through a conventional load balancer and be handled by any available MCP server because information needed for the interaction travels through the transport instead of depending implicitly on one server instance. Interchangeable instances can consequently fit the Kubernetes and cloud-native operating patterns many organizations already use. Gilbert summarized the infrastructure consequence: “That stateless capability enables your MCP client to speak to a load balancer that connects with any server. You don’t need the stickiness.”

The operating model matters more as the number of agents grows. Gilbert says he has encountered companies deploying “tens of thousands of agents,” where maintaining server affinity for each interaction creates an infrastructure constraint independent of agent capability. “It wasn’t the technology, it wasn’t the business case, it was really these fundamental changes that were required,” he said. For those organizations, adopting MCP was partly an operations decision because the protocol had to behave predictably inside existing distributed infrastructure.

The scale problem had been visible almost from MCP’s launch. In December 2024, only weeks after the protocol appeared, co-creator Justin Spahr-Summers opened a public GitHub design discussion identifying long-lived, stateful connections as a limitation for serverless deployment. Participants considered three architectural paths, including the fully stateless direction now largely adopted. Engineers from Vercel, Cloudflare, Shopify, and Amazon joined over the following months, connecting the transport problem to several kinds of infrastructure and application workload.

That public discussion later became a formal design direction. According to the release announcement, the core maintainers committed to the transport approach at a December 2025 meeting about MCP’s future transports. The time between the early GitHub discussion and that decision matters because moving state changes who must manage it. MCP can now fit a standard load-balanced deployment, while applications continue to maintain the state their own workflows require.

Soria Parra makes that boundary explicit. “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,” he said. Moving more information with an interaction increases message size, creating a concrete cost for the new operating model. “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,” he said.

The transport cost comes with a change in application responsibility. “With statelessness, we did shift the responsibility of creating and managing state to the developers, but very intentionally so,” Delimarsky said. Under the previous design, he said, developers repeatedly struggled with whether protocol state was required, where it belonged, and how they should use it. The new boundary makes the choice explicit: developers manage state appropriate to their environment, while the transport can route requests among interchangeable server instances.

Moving responsibility also narrows behavior that depended on a persistent server relationship. One example is out-of-band server logging, which allowed a server to send informational logs to a client independently of the normal request flow. Before removing that behavior, maintainers scraped GitHub to measure use; Soria Parra said it was essentially nonexistent and estimated the affected population at “probably a handful of people, quite literally a handful of people.” That usage evidence gave maintainers a basis for choosing simpler transport semantics despite the compatibility cost.

Soria Parra also described the personal trade-off involved in dropping behavior he had expected people to use. “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.” For engineering leaders, the cost boundary is concrete: stateless transport brings larger payloads, explicit application-state management, and the removal of some behavior that relied on persistent connections.

Enterprise readiness also requires identity, security, and a stable change contract

The transport redesign addresses large fleets, but smaller deployments can encounter security and lifecycle constraints earlier. Gilbert says authorization and identity gaps, together with uncertainty about specification changes, have slowed those adopters. “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 organizations, he added, “are going to benefit not because of the statelessness. They’re going to benefit because of the security.”

That security work increasingly aligns MCP with OAuth 2.0, the established authorization framework, and OpenID Connect, the identity layer commonly used with it. One concrete hardening measure is mandatory validation of the issuer, or iss, value, which identifies the identity server that issued an authorization response. A client must verify that the response came from the expected identity server. The check closes the protocol path for identity-server mix-up attacks and gives implementations a defined requirement to enforce consistently.

The issuer requirement reflects preventive engineering. “This is not something that is gated in any existing vulnerabilities or active exploitation,” Delimarsky said. “This is more of us engaging directly with the security community.” He described the broader design principle as reuse of established security practice: “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 identity work is also expanding from an individual login to organization-wide authorization. Enterprise Managed Authorization, developed with identity provider Okta, lets a company’s identity provider act as the authoritative gatekeeper for access to MCP servers. Okta can benefit commercially as enterprise identity controls become more important to MCP deployments, while the underlying mechanism was developed as an open standard. An employee can authenticate with corporate credentials, allowing the organization to apply common access rules across a fleet and control where clients may send organizational data.

The organization-wide model matters when one administrator manages many servers. “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 open standard beneath Enterprise Managed Authorization, after which maintainers worked to support ecosystem-wide adoption across identity vendors.

Current authorization work also creates a base for stronger mechanisms security teams are requesting. Proposed additions include demonstrated proof-of-possession, where a caller proves control of credential material associated with an authorization, and workload identity federation, which lets software workloads establish identity across different environments. Gilbert argues that the combined authorization work has moved MCP toward what he calls “enterprise ready” and away from an “open lab sort of experiment.” His AAIF role gives him an institutional interest in that maturation claim, and the additional production-security capabilities remain proposals.

Security for a long-lived dependency also requires predictable protocol change. MCP now has a formal 12-month deprecation policy: after a feature is formally deprecated, at least twelve months must pass before maintainers may remove it. Removal becomes permissible after that period and remains a separate decision. The process moves from deprecation through a minimum observation period and feedback collection before maintainers decide whether removal should proceed.

The twelve-month interval came from deployment-cycle discussions with Google, Microsoft, and Amazon, all of which participate in the AI and cloud markets that can benefit from predictable MCP infrastructure. “Twelve months seemed like the reasonable middle ground,” Delimarsky said. He also tied deprecation to implementation demand: “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.” For adopters, the policy becomes part of the operating contract governing how quickly an implementation can be forced to migrate.

Observed upgrade behavior gives that contract practical context. Maintainer telemetry indicates that most of the ecosystem upgrades within six to eight months, leaving additional time inside the minimum twelve-month period for slower deployments and implementation feedback. “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. I think it’s more of a feedback period than a definite period,” Soria Parra said. The guarantee fixes the earliest removal date while leaving maintainers free to retain a deprecated capability.

That migration process also depends on MCP’s official SDK ecosystem, which includes TypeScript, Python, C#, Rust, Java, and other languages. Many implementations rely on those software development kits, so some protocol changes can be absorbed in shared libraries and then flow into applications through SDK upgrades. “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. His remark also shows that AI coding assistants are affecting maintainers’ expectations for migration effort.

Tasks, richer interactions, and extensions build on the new transport

With transport and lifecycle behavior becoming more predictable, MCP can support operations that last beyond a short request-response exchange. A new extension framework allows optional capabilities to evolve separately from the core specification, keeping the core narrower while specialized features follow their own schedules. MCP Tasks and MCP Apps have now graduated into official extensions under that structure. Both depend on the lifecycle rules below them because their interactions are more complex than returning a simple text result.

MCP Tasks handles durable asynchronous work, meaning work that continues while the client is disconnected. A server can start a long-running operation and return a durable task handle, allowing the client to disconnect, crash, or restart before resuming polling for completion. Delimarsky used processing podcast audio or video as the concrete example: “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.”

Multi-round-trip requests solve a second workload shape in which an operation needs more information before execution. Client and server can exchange parameters or other required input during one logical operation, then proceed when the required information has been established. “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.”

MCP Apps extends the same interaction model into presentation. Servers can render rich interactive interfaces inside AI clients, providing a dashboard for inspecting data, a form for structured input, or a visualization for results that are easier to understand graphically. Those user-facing interactions put more weight on transport and lifecycle behavior because the MCP connection can sit beneath application experiences people directly use. Infrastructure failures can consequently become visible product failures rather than background tool errors.

Those production requirements help explain why large technology companies have influenced the release. Soria Parra says distributed-systems experts at Microsoft, Google, and other companies worked on changes driven by their own deployments and broader industry requirements. Microsoft and Google have commercial interests in agent and cloud infrastructure, so improvements that make MCP easier to deploy can benefit their products as well as other implementers. Their involvement also raises the next enterprise dependency question: who controls a specification shaped by competing suppliers?

Governance has broadened while formal authority remains concentrated

That control question changed materially when Anthropic donated MCP in December 2025 to the newly formed AAIF under the Linux Foundation. Anthropic had created the protocol in November 2024, while Block contributed an AAIF founding project and OpenAI supplied another founding project. Seven months after the donation, AAIF is MCP’s steward as a directed fund, a Linux Foundation structure through which designated participants oversee funding and governance for a defined project area. The arrangement places competing AI companies inside a common institutional venue.

The maintainer group has broadened along with that transfer. Core maintainers now represent Anthropic, Microsoft, OpenAI, Google, and Amazon, companies that compete across AI, cloud, models, and developer platforms, while contributors include companies such as Block. Their shared participation should therefore be read in the context of commercial competition rather than as neutral analysis from independent observers. Soria Parra says important decisions are “usually unanimous,” and describes Anthropic’s position this way: “Technically we have a lot of influence; de facto, we‘re not exerting any of it.”

Formal authority still differs from the broader participation around it. Soria Parra remains an Anthropic employee and acknowledged, “I do have veto rights, technically,” while adding, “but I think we have never actively used it in any kind of discussion.” An unused veto remains relevant to institutional neutrality because consensus in current decisions and the formal power to block a decision are separate properties. Soria Parra expects governance structures to expand over time to include more participants.

The foundation around that governance structure is also adding members quickly. Gilbert estimates that Anthropic’s contribution share has fallen below half, while AAIF’s organization count and recruitment pace have changed as follows:

Gilbert calls AAIF “the fastest growing foundation” by membership in Linux Foundation history. As AAIF’s executive director, he has an institutional interest in membership growth being viewed as evidence of the foundation’s strength. A larger membership base creates more potential participants in standards work, while technical authority still follows the project’s governance rules.

The kind of organization joining AAIF adds another dimension to that growth. Participation now extends beyond conventional technology suppliers into retail, finance, and telecom, and the roster includes CERN and Consumer Reports. Gilbert says adopters increasingly want to shape protocols from their inception, giving them a role while standards are still being formed. He explains Consumer Reports’ presence as important “because somebody has to defend consumers when this internet of agents comes alive.”

That broader participation also supports Gilbert’s standard-setting philosophy. “Holding control of a project doesn’t make it an open standard,” he said. “You have to let go. You have to contribute, and you have to grow the pie and the community. And Anthropic has done an incredible job doing exactly that.” Because Gilbert leads the foundation receiving Anthropic’s project, his praise comes from an organization that benefits from a successful transfer and expanding community.

The governance challenge is harder because participating vendors remain active competitors. Gilbert describes the foundation as a place “where competitors who compete furiously during daytime” can “come to a neutral room and debate, converse, align, consolidate, and drive open standards of how the Internet of Agents will evolve.” His professional background at Google and AT&T, along with experience establishing foundations with the Linux Foundation, informs that standards-oriented approach. MCP’s trajectory now runs from Anthropic’s donation through broader maintainer representation and mostly unanimous decisions toward governance structures expected to include still more parties.

AAIF is extending that participation geographically as well. AGNTCon and MCPCon events are planned for this fall in Shanghai, Tokyo, Amsterdam, and San Jose, with additional events planned in South Korea, Nairobi, and Toronto. Gilbert is also investing in membership growth across Asia and India, which he sees as underdeveloped markets for foundation expansion. That geographic effort serves AAIF’s growth goals while broadening the set of technology ecosystems in which MCP could become common infrastructure.

The geographic push connects directly to model interoperability. “We‘re completely agnostic to what the model is, whether the model is Kimi, or Gemma, or a frontier model from Anthropic, or from anybody,” Gilbert said. “Every model will have to support MCP, whether it is a Chinese model or whether it is a U.S. model, it doesn’t matter. The protocols must be open, standardized.” He argues that enterprises already choose models “left, right, and center” according to their needs, which increases the value of common interfaces as model choice diversifies.

Production behavior is the next adoption test

That interoperability ambition already sits on top of a large developer ecosystem. Soria Parra says SDK downloads doubled during the previous six months and now reach roughly 250 million per week, figures he called “insane numbers.” When Anthropic donated MCP in December 2025, it had reported 97 million monthly downloads across the Python and TypeScript SDKs alone. Because the figures cover different SDK scopes and time periods, they describe growth without forming a like-for-like performance comparison.

That download growth accompanied a rapid organizational change. Soria Parra says MCP was an Anthropic-only project eighteen months earlier, had substantial outside engagement twelve months earlier, and is now what he describes as a global community. Delimarsky says the project is reaching an “inflection point” where it becomes a substrate, meaning a shared technical layer, for agentic workflows across enterprises, startups, and other organizations. Both maintainers also credit the large group of volunteers contributing their own time alongside the major vendors.

Production deployment now provides a different measure from SDK downloads. Maintainers plan to watch how many servers implement the new specification, whether major drivers such as Microsoft and Google deploy it, and what implementers report through MCP working groups, GitHub, and Discord. Soria Parra says Microsoft and Google have driven many of the changes and that early implementation signals are “very, very positive.” Those companies also benefit commercially from infrastructure that supports their AI and cloud offerings, making deployed behavior an important check on vendor expectations.

The next AAIF projects will increase the load placed on that production foundation. Its newly announced Agent Gateway project addresses traffic management and policy enforcement, while Gilbert sees agentic commerce as a future MCP use case in which merchants expose products and services so agents can discover them. Those applications could span Kimi, Gemma, Anthropic models, Chinese models, U.S. models, and others as enterprises select different models for different jobs. Common interchange becomes more consequential as that mix expands.

That expansion puts MCP on a longer infrastructure timetable than its early adoption numbers suggest. Gilbert compares the emerging environment with web infrastructure that developed broad trust over roughly thirty years, while what he calls the “internet of agents” remains in its “first, second year.” Production deployments will now show how the new transport, authorization rules, deprecation process, extensions, and governance arrangements behave as dependencies under real operating conditions. The governance test will continue in parallel as AAIF grows and formal authority evolves around the competing companies building on MCP.

Key takeaways for decision-makers

• Design MCP for cloud-scale operations: Stateless transport lets MCP clients route requests through standard load balancers to interchangeable server instances. Platform teams evaluating MCP at scale should account for larger payloads and move application-specific state management into their own architecture.
• Treat identity and lifecycle policy as production requirements: MCP now strengthens OAuth and OpenID Connect integration, supports enterprise-managed authorization, and guarantees at least 12 months between formal deprecation and possible removal. Security and platform teams can use these controls to align MCP deployments with corporate identity policies and upgrade cycles.
• Use extensions for durable agent workflows: MCP Tasks supports asynchronous work and multi-step interactions, while MCP Apps enables interactive interfaces inside AI clients. Product and engineering teams can evaluate these extensions for workloads that outlive a single request or require structured user interaction.
• Evaluate governance alongside technical maturity: MCP now sits under the Linux Foundation’s AAIF with maintainers from Anthropic, Microsoft, OpenAI, Google, and Amazon. Procurement and architecture teams should still account for concentrated formal authority, including an Anthropic employee’s technical veto, when assessing MCP as a strategic dependency.
• Measure production adoption as the next maturity test: MCP SDK downloads have grown rapidly, but production deployments will provide stronger evidence that the new transport, security controls, extensions, and governance model hold up at enterprise scale. Technology leaders can track server implementation, major vendor deployments, and operational feedback before making MCP a deeper infrastructure dependency.