What Enterprise MCP Rollouts Look Like at Scale

MCP server downloads grew from roughly 100,000 in November 2024 to over 8 million by April 2025. SDK downloads had reached roughly 250 million per week by mid-2026, with both the TypeScript and Python SDKs crossing 1 billion total downloads. GitHub MCP repositories went from roughly 2,000 in Q1 2025 to roughly 12,000 a year later. These figures require sourcing before the growth rate can be characterized as indicative of infrastructure adoption rather than developer trend.

The enterprise numbers track the same direction. As of Q1 2025, 28% of Fortune 500 companies had MCP servers running in production, up from 12% the prior quarter. By mid-2026, 78% of enterprise AI teams reported at least one MCP-backed agent in production, spread across financial services, healthcare, and professional services. Separately, 41% of surveyed software organizations report running MCP servers in limited or broad production. Fintech leads at 45%, driven by multi-system data requirements and heavy API usage. Healthcare sits at the low end, though that reflects regulatory friction more than disinterest. Sources for these figures should be cited to allow verification.

Gartner projects 40% of enterprise applications will include AI agents by end of 2026, up from under 5%, and that 75% of API-gateway vendors will have MCP features by then. The governance infrastructure to support that footprint has not kept pace with deployments. That gap is the central operational fact of MCP at scale, and most organizations are only now reckoning with it seriously.

What Early Enterprise Deployments Actually Built, and What They Learned Doing It

Block is the clearest early-scale case. They built an internal AI agent called Goose on MCP architecture, deployable as both a desktop application and a command-line tool, and constructed more than 60 MCP servers entirely in-house. That was a deliberate control decision. The results were substantial: 50 to 75% time savings on common tasks, with some multi-day tasks compressed to hours. Use cases spanned code migration, QA, support ticket triage, and cross-system automation. What Block demonstrated is that owning the full server stack gives security control and workflow customization that off-the-shelf servers cannot match. The engineering investment to get there is significant, and most organizations are not positioned to replicate it at the outset.

Bloomberg built something architecturally distinct. Their GenAI platform scaled to production across more than 9,500 engineers using MCP. They applied dependency inversion: agents, tools, and LLMs built to standardized, swappable interfaces, with prompts and toolchains treated as configuration rather than hardcoded logic. They built remote multi-tenant MCP servers with identity-awareness and separated agent logic from application logic. Experimentation cycles dropped from weeks to minutes. Because MCP had achieved multi-vendor adoption, Bloomberg's internally built tools became usable with third-party client applications without additional custom integration.

Bloomberg's own enterprise MCP team also issued a caution worth noting: financial institutions building AI strategies on top of early-stage MCP implementations are, in many cases, inheriting problems their vendors have not yet solved.

Amazon's adoption followed a different path. Teams there had been required to build internal APIs since the mid-2000s. That existing infrastructure created low-friction MCP adoption; the culture had internalized API-first thinking long before AI agents existed, and it showed in how quickly they moved.

Honeycomb.io offers a production signal that reframes the scale conversation. A substantial share of all monthly interactive queries are now made by agents, not humans. When one in five queries comes from an agent, the operational assumptions that governed human-facing infrastructure no longer hold. Capacity planning, access control, observability: all of it needs rethinking from first principles.

Across these cases, the organizations that scaled fastest had existing API discipline, clear ownership of their server inventory, and treated MCP architecture as an infrastructure decision from day one. The ones that treated it as a tooling preference they could govern later are now doing the harder retrofit work.

The Stateful Architecture Problem That Blocked Horizontal Scaling, and How It Was Resolved

MCP's original session-based, stateful transport model was a genuine infrastructure ceiling. Stateful sessions conflict with load balancers. Horizontal scaling required workarounds. There was no standard way for a registry or crawler to discover what a server does without connecting to it first. Caitie McCaffrey, a Microsoft software engineer and core MCP maintainer, described the practical consequence clearly: this made implementing and operating MCP in large-scale production environments incredibly complex, even though the exposed functionality itself was stateless.

A protocol update released July 28, 2026, under the Agentic AI Foundation finalized MCP's transition to a fully stateless architecture. A remote MCP server that previously required sticky sessions, a shared session store, and deep packet inspection can now run behind a plain round-robin load balancer. Traffic routing operates on an Mcp-Method header, clients can cache tool-list responses, and the update shipped defenses against OAuth mix-up attacks along with a formal 12-month deprecation policy. That last piece matters specifically for enterprise migration planning, where surprise deprecations create real operational risk. Two capabilities also graduated to official protocol extensions: interactive server-rendered interfaces and long-running asynchronous tasks.

For teams with existing deployments, the migration is not trivial. Enterprises running multiple HTTP servers behind an API gateway with production agents and active task workflows should budget six to twelve weeks of platform engineering for the transition.

The stateless update removes a real constraint. What it does not address is the governance and security debt that accumulates as server counts grow. Those require a separate layer, and most organizations are currently underinvested there.

Why Authentication and Authorization Are the Central Operational Challenge as MCP Deployments Grow

MCP's original model was designed for a 1:1 deployment scenario: a client and a server on a developer's local machine. That was the right design for its initial context. It created structural authorization gaps at enterprise scale, where agents call multiple servers, servers serve multiple clients, and identity needs to be verifiable across all of it.

Anthropic released the first authorization specification in March 2025, enabling OAuth 2.1 access, but with no separation between authentication and resource servers, only a blended model. Repeated authorization prompts became a documented pain point. The standard model was user-scoped and tied to interactive authentication conventions, which works fine for individual users and is deeply impractical for agents running at scale.

The current answer is the Enterprise-Managed Authorization extension, now stable. Organizations can centrally manage authorization for MCP servers, and end-users access all connected servers through a single login. Anthropic, Microsoft, and Okta have adopted it, using Okta's Cross App Access approach as the first supported implementation path. Server-side adopters at launch include Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase. Enterprise-Managed Authorization matters beyond user experience because centralized authentication is the prerequisite for centralized policy enforcement. You cannot control what you cannot identify, and for a long time MCP gave enterprises very little to identify.

AWS's approach through Bedrock AgentCore is worth noting alongside this: On-Behalf-Of token exchange and Cedar-policy tool-level authorization represent a vendor-specific implementation of the same underlying operational requirement.

Authentication is solvable at the protocol level now. The qualifier that matters: only for organizations that actively implement it. The default remains permissive, and permissive defaults at enterprise scale carry meaningful operational risk.

The Security Vulnerabilities That Emerge When MCP Servers Proliferate Without Governance

A July 2025 internet scan identified at least 1,862 publicly accessible MCP server instances responding to unauthenticated requests. The authorization specification marks authentication as optional, which means servers are exposed by default unless someone makes a deliberate choice otherwise. Most environments do not.

The vulnerability classes that have materialized are specific and documented. Invariant Labs demonstrated in April 2025 that MCP is vulnerable to prompt injection via malicious tool descriptions. In one documented example, an attacker extracted WhatsApp message history by altering a seemingly benign tool description. The mechanism is straightforward: if an agent trusts tool descriptions, and tool descriptions can be modified, the agent's trust becomes an attack surface. CVE-2025-6514 in the mcp-remote package compromised over 437,000 developer environments through a shell command injection vulnerability in a widely used dependency. The first malicious MCP package appeared in September 2025 and operated undetected for two weeks while exfiltrating email data. More than 30 CVEs were filed in January and February 2026 alone.

Only 18% of MCP deployments implement any form of access scoping for tool parameters and permissions. The large majority lack that scoping, which means incidents in those environments are often discovered well after the fact.

Regulatory pressure has moved past the theoretical. EU AI Act Article 12 requires high-risk AI systems to enable automatic logging sufficient for post-hoc reconstruction of individual AI-assisted decisions. Full enforcement began August 2, 2026. MCP tool call activity in customer support, financial analysis, and HR automation is in scope. Organizations without tool-call logging are already out of compliance — full enforcement is active and the deadline has passed.

What Governance Infrastructure an Enterprise MCP Deployment Needs Once Server Counts Reach Production Scale

Block and Bloomberg succeeded partly because they made explicit architectural decisions about server ownership and identity from the start. Organizations that deferred those decisions are now retrofitting governance onto infrastructure that was not designed to accommodate it.

There are four capabilities that stop functioning as optional features once server counts reach production scale.

Server registry. Every MCP server an organization runs needs a registry entry: name, owner, tool set, authorization policy. An unregistered server is an identity the organization cannot account for and cannot audit. Windows 11's on-device MCP registry is an early vendor implementation of this principle at the OS layer. The same logic applies to every server in an enterprise environment, not just those managed at the OS level.

Access control. Role-based access for AI agents ensures that what agents can reach reflects a deliberate organizational decision rather than a default. Enterprise-Managed Authorization and AWS's Cedar-policy implementation are two current paths. Both require organizational policy to be defined before they can be enforced, which means the governance work precedes the technical implementation, not the other way around.

Gateway layer. Routing all MCP traffic through a central gateway enables policy enforcement, tool call inspection, and anomaly detection at a point the organization controls. The July 2026 stateless update makes this significantly easier to operate than it was six months prior.

Real-time observability. Audit logs read after an incident are a postmortem capability. The governance value is in visibility at the moment of access. EU AI Act Article 12 compliance requires logging sufficient for post-hoc reconstruction, and real-time systems satisfy that requirement while adding operational value that extends well beyond the compliance checkbox.

One failure mode deserves direct naming because it is common: blocking MCP servers entirely pushes adoption underground. Teams that cannot get a governed path to the tools they need will find an ungoverned one. Providing a clear, auditable path to MCP capability is the mechanism by which the organization stays in the picture at all.

Adoption starts with a few servers, usually built by a small team with a specific use case. Server counts grow, often faster than anyone planned. The governance infrastructure required to manage those servers at scale is not the same infrastructure that was adequate when there were three of them. The organizations that recognize that inflection point and invest ahead of it retain operational control. The ones that do not are already learning what it costs to recover it.