Model Context Protocol (MCP): Why It's Becoming the Enterprise AI Integration Standard in 2026

Direct answer: Model Context Protocol (MCP) is an open specification — originally authored by Anthropic — that standardizes how AI models and agents connect to external tools, data sources, and systems, replacing bespoke integration code with a single, reusable interface. It matters right now because adoption went from roughly 100,000 downloads at launch to an ecosystem reportedly seeing around 97 million monthly SDK downloads in under two years, with OpenAI, Google, Microsoft, and Salesforce all shipping support within about 13 months of one another. That convergence has made MCP the closest thing agentic AI has to a shared integration standard, even as some of the more specific adoption-rate claims circulating about it are getting real scrutiny.

A Launch That Turned Into the Industry's Default Wiring

Every enterprise that has tried to connect an AI model to more than one or two real systems has run into the same wall: an AI application that needs to reach a CRM, a ticketing system, a file store, and an internal database ends up writing custom integration code for each one, and each of those systems ends up fielding custom integration requests from every AI application that wants to talk to it. Multiply the number of AI applications by the number of tools and data sources they each need, and the integration work grows combinatorially — engineers call this the "M×N problem," and it is the single biggest reason agentic AI pilots stall before they reach production. Every connector is bespoke, every connector needs its own authentication handling, its own error handling, its own maintenance burden when either side changes its API.

Model Context Protocol exists to collapse that M×N problem into something closer to M+N: a tool or data source implements one MCP server, once, and any MCP-compatible AI application — a client — can discover and call it without custom glue code. A company that exposes its internal knowledge base, its support ticketing system, and its deployment pipeline as MCP servers has done that integration work exactly once per system, not once per AI application that might eventually want to use it. That is the entire value proposition, and it is also why the growth curve has been so steep: once a handful of tools are wired up as MCP servers, every new AI client that speaks MCP gets access to all of them for free.

The numbers behind that growth curve are genuinely striking. MCP launched with something like 100,000 downloads — a respectable but unremarkable start for a developer-facing spec. In under two years, that grew to an ecosystem reportedly seeing on the order of 97 million monthly SDK downloads, per Anthropic's own ecosystem announcement as tracked in DigitalApplied's "MCP Adoption Statistics 2026" analysis. Reaching that scale that quickly is unusual for any open specification, let alone one that started as a single vendor's internal tooling decision. CData's 2026 analysis, titled plainly "2026: The Year for Enterprise-Ready MCP Adoption," frames this as the year MCP stops being a novelty developers experiment with on the side and starts being infrastructure that enterprise architecture teams are expected to plan around — the same way REST APIs or OAuth eventually stopped being optional knowledge for anyone building integrations.

What makes this particular growth curve worth taking seriously, rather than treating as one more AI hype metric, is who else showed up. Within roughly 13 months of each other, OpenAI, Google, Microsoft, and Salesforce all shipped MCP support across their own AI platforms — direct competitors to Anthropic and to each other, converging on a shared plumbing layer that none of them controls outright. That kind of convergence is rare in a market this competitive, and it typically only happens when every player independently concludes that owning a proprietary integration format is more expensive than sharing a neutral one. None of them wanted to be the platform that made every partner and customer write custom connector code just for their ecosystem, so they all backed the standard that let them avoid it.

This is also why "MCP adoption" is not really one number, but at least three different ones that get conflated in casual coverage: how many people have downloaded an MCP SDK, how many MCP servers exist for others to connect to, and how many organizations are actually running MCP against production systems rather than experimenting with it. Each of those measures something real, but they answer different questions, and a lot of the confusion around MCP statistics — including the specific reliability concerns raised about some of 2026's more widely repeated adoption percentages — comes from treating one of those three measures as if it were the others.

MCP vs. Function Calling: What Actually Changed

It is easy to conflate MCP with "function calling" or "tool use" because both terms describe an AI model taking an action beyond generating text, but they answer different questions. Function calling — sometimes called tool calling — is the capability: a model decides, based on the current conversation or task, that it should invoke a specific function with specific arguments, and the surrounding application code executes that call and returns a result. Every major model provider has supported some version of function calling for a while, and it is the mechanism that makes agents possible in the first place.

MCP is not a replacement for function calling — it is the protocol for exposing and discovering the tools a model can call, standardized enough that the same tool integration works across many different AI applications instead of being rebuilt for each one. Before MCP, an engineering team building an AI assistant that needed to call a company's internal ticketing API had to write that integration specifically for their chosen framework's function-calling format. If a second team, using a different framework or a different model provider, wanted the same ticketing integration, they wrote it again, in a different shape, with different assumptions about authentication and error handling. MCP standardizes that description layer: a server declares its available tools, resources, and prompts once, in a consistent schema, and any MCP-compliant client can discover and call them the same way regardless of which underlying model or framework it's built on.

The transport layer has evolved alongside this. Early MCP implementations leaned on local process communication (well-suited to a single developer running tools on their own machine) and an HTTP-plus-server-sent-events pattern for early remote deployments. As enterprises started wanting to expose MCP servers across a network — behind a firewall, authenticated, reachable by multiple teams and applications rather than one developer's laptop — Streamable HTTP has become the current standard transport for remote MCP, a detail that matters more than it sounds because transport scalability is explicitly named as one of the protocol's own priorities for 2026. A protocol that only works well on localhost is a developer toy; a protocol with a network-ready transport is infrastructure.

Inside the Numbers: Registries, SDKs, and Who's Actually Shipping

Two figures worth holding side by side, because they measure genuinely different things: as of a May 24, 2026 snapshot, the official MCP Registry listed 9,652 servers, while a separate count of GitHub repositories tagged as MCP servers found 15,926. The gap between those two numbers is not a discrepancy to be resolved — it is a description of how open ecosystems actually grow. The official registry is a curated, discoverable index, closer to a package registry like npm's featured listings than to "everything that exists." The broader GitHub count captures the full sprawl of an open ecosystem: personal projects, experiments, forks, abandoned prototypes, and genuinely production-grade servers that simply haven't been submitted to the official registry yet. A healthy open protocol produces exactly this pattern — a large, messy periphery of community activity around a smaller, more curated center — and the fact that MCP already shows that shape after roughly two years is itself a signal of real, organic adoption rather than adoption manufactured by a single vendor's marketing push.

The production-readiness picture is more conservative than the download and repository numbers suggest, and that is worth sitting with rather than smoothing over. Stacklok's 2026 survey found that 41% of enterprises report MCP use in limited or broad production — meaningfully short of full-scale, MCP-everywhere deployment, but also a real, substantial minority actually running it against live systems rather than just kicking the tires in a sandbox. Read against the SDK download and registry figures, this paints a coherent, not contradictory, picture: a very large base of developer experimentation and internal tooling, with a smaller but still significant slice of that experimentation graduating into production.

Gartner's forecast adds another dimension entirely — it projects that 75% of API gateway vendors will have MCP capability by the end of 2026. That is a meaningfully different kind of adoption signal than a developer downloading an SDK. API gateways are the infrastructure layer that already sits in front of most enterprise APIs, managing authentication, rate limiting, and routing; if three-quarters of that vendor category ships MCP support, MCP is being absorbed into general-purpose infrastructure rather than staying a bespoke, AI-team-only concern. That is the pattern that separates a genuinely durable standard from a trend that fades once the initial hype cycle passes — REST, OAuth, and GraphQL all went through a comparable phase where the underlying infrastructure vendors started shipping native support rather than leaving it to application-layer workarounds.

It's also worth naming the adjacent, complementary effort explicitly: Agent-to-Agent (A2A) protocol work targets a different connection than MCP does. MCP standardizes how an agent connects to tools and data; A2A targets how multiple agents coordinate and communicate with each other. The two are frequently mentioned together because a mature agentic AI stack plausibly needs both — a standard way for an agent to reach its tools, and a standard way for agents built by different teams or vendors to hand off work to one another — and the Model Context Protocol Blog's own 2026 roadmap names agent-to-agent communication as one of four priorities for the year, alongside transport scalability, governance maturation, and general enterprise readiness.

Why 2026, Specifically, Is the Inflection Point

For a while, "agentic AI" mostly meant a chatbot that could look something up and answer in a single turn. The shift that has actually driven MCP's growth curve is that production AI systems stopped being single-turn question-answering and started being expected to reach into a dozen real enterprise systems in the course of one task — checking an order status, cross-referencing a policy document, updating a record, and notifying a person, all inside what a user experiences as one continuous interaction. That shift turns integration work from a one-time setup cost into a recurring, compounding one: every new system a company's agents need to reach is another custom connector, unless there's a standard way to expose it once and let every future agent reuse it.

That timing lines up tightly with the emergence of genuinely agentic — as opposed to purely conversational — AI products across every major vendor at roughly the same moment. A model that only ever answers in text doesn't need a standardized tool-connection protocol; a plain, direct API call from the surrounding application handles that case fine. A model that's expected to autonomously decide which of a dozen available systems to check, in what order, based on what it finds along the way, needs a consistent and discoverable way to know what's available to call and how to call it safely. That need is exactly what MCP was built to satisfy, and it's also precisely the capability every major AI lab spent the last two years racing to ship. The protocol and the underlying agentic capability effectively grew up together, which is a large part of why adoption compounded this fast instead of following the slower, multi-year curve most infrastructure standards take before anyone outside a niche developer community notices them.

The Model Context Protocol Blog's own 2026 roadmap reads as confirmation of this rather than a surprise. Of its four stated priorities — transport scalability, agent-to-agent communication, governance maturation, and enterprise readiness — three of the four are explicitly about handling scale and real production conditions, not about adding brand-new core capability to the protocol itself. That's the signature of a specification that has already validated its core idea and is now doing the harder, less visible work of making that idea hold up under enterprise load: multiple teams hitting the same server concurrently, servers that need to be discoverable and auditable at a company-wide scale rather than a single developer's laptop, and governance processes mature enough that a security team can actually answer "what does this specific MCP server have access to" with confidence instead of guesswork.

It's worth being explicit about what has not driven this growth curve, too, because it cuts against the more breathless version of the MCP story that sometimes circulates. Nothing in the research behind this piece points to a regulatory mandate, a dominant vendor's deliberate lock-in strategy, or one killer application pushing adoption this fast. It looks much more like organic convergence — many independent teams and companies, facing the identical integration cost, arriving at the same conclusion that a shared protocol was cheaper to depend on than each team building and maintaining its own proprietary version. That is a more durable foundation for a standard to stand on than a mandate or a single vendor's marketing push would be, precisely because the incentive to keep using it doesn't depend on any one company's continued backing or goodwill.

Who This Actually Affects

The clearest way to see how far MCP's reach extends is to look at who has to make a decision about it, not just who benefits from it.

Platform and infrastructure vendors are under direct competitive pressure. If three-quarters of API gateway vendors are expected to ship MCP capability by the end of 2026, the remaining quarter isn't choosing between "MCP or no MCP" so much as choosing how much longer they can defer a decision their buyers are increasingly going to ask about during procurement.

Enterprise platform engineering and AI infrastructure teams get the most direct operational benefit. A team that has already stood up two or three MCP servers for its most-used internal systems has effectively built a reusable integration layer that every future internal agent project can draw on instead of re-solving the same connector problem from scratch — which is exactly the kind of foundational, unglamorous infrastructure work that determines whether an organization's tenth agent project ships in weeks or in quarters.

AI application and agent-framework vendors face the same convergence pressure as the API gateway category. Once enterprise buyers start treating MCP compatibility as a baseline procurement checkbox rather than a nice-to-have, a vendor without it is negotiating from a weaker position regardless of how good their underlying model or agent orchestration is.

Security and compliance teams inherit a genuinely new category of risk surface, and this is the group most likely to get looped in too late. Every MCP server a company stands up, or connects to from a vendor, is a new point where an AI agent's runtime gets privileged access to a real system — and unlike a human employee with an onboarding process and an access review cadence, an MCP server can be spun up by an engineering team on a Friday afternoon without anyone from security ever reviewing what it actually exposes. Our overview of security practices covers how this kind of privileged-access surface should be reviewed before it goes anywhere near production data, and the same discipline that applies to any new integration with write access to a live system applies here — arguably more so, because the thing calling that integration is making its own decisions about when to call it.

Procurement and vendor-management functions are the newest addition to this list, and mostly by osmosis rather than formal policy: "does this support MCP" is turning into a standard question in enterprise AI vendor evaluations the same way "does this support SSO" became one for SaaS a decade earlier.

Individual developers and engineering teams feel the effect most directly day to day, even if they never touch the strategic decisions above. A developer who used to spend a week writing and testing a bespoke connector to an internal system now spends that time on the actual agent logic, because the connector either already exists as an MCP server or takes a fraction of the effort to stand up as one. That shift in where engineering time actually goes — away from repetitive integration plumbing and toward the parts of an agent project that are genuinely specific to the business problem — is the kind of productivity change that shows up in project timelines and internal roadmaps well before it ever shows up in an adoption survey.

Taken together, this is why MCP's reach extends well past AI teams narrowly defined: it touches how vendors compete, how security teams scope their review workload, how procurement writes its checklists, and how individual engineers actually spend their week — which is a much broader footprint than a typical developer-tooling spec has at the two-year mark.

The Global Adoption Picture

Most of the hard numbers behind MCP's growth — the download counts, the registry size, the production-adoption percentage — are reported globally or at the level of the overall enterprise AI ecosystem, not broken out by country. That is worth stating plainly rather than papering over: across the US, UK, UAE and Dubai, Australia, and Germany, this research did not surface a region-specific MCP adoption statistic distinct from the worldwide figures already covered above. That is itself informative — it suggests MCP's adoption story, unlike broader agentic AI adoption more generally, is still being told almost entirely at the protocol-and-vendor-ecosystem level rather than the country-market level, which is typical for infrastructure standards in their first couple of years before national analyst firms and local trade press start producing their own market-sizing research.

Europe offers one genuinely distinct data point, and it's a strategic one rather than an adoption statistic. France's sovereign-AI vendors are positioned less as MCP adopters and more as deliberate architectural alternatives — Mistral AI, the country's flagship AI company, ships its own Agents API that bundles function-calling, tool use, and memory directly, rather than routing through MCP as an external standard. That is not evidence against MCP's momentum elsewhere; it is evidence that a vendor with enough scale and enough strategic motivation to control its own stack can reasonably choose not to depend on any external protocol, MCP included, and that sovereignty-driven technology strategy is a live consideration in Europe's AI market in a way it isn't for most vendors elsewhere.

China presents the most interesting regional signal of all, because it is a live, open question rather than a settled adoption fact. Chinese enterprise buyers are reported to still be asking, plainly, "do we need the MCP protocol at all" — one of seven FAQ items surfaced in a 2026 China-market agent guide, sitting alongside questions about the difference between RPA and genuine agentic AI and the economics of building versus buying agent infrastructure. That framing matters: it means MCP's value proposition — solving the M×N integration problem — hasn't yet been treated as self-evidently necessary in every major market, and some buyers are reasonably asking whether their specific integration needs justify adopting an external standard versus building more narrowly for their own stack.

Security, Governance, and the Real Open Questions

The same openness that let MCP's ecosystem grow to nearly 16,000 GitHub repositories in under two years is also its most honest security liability, and it's worth naming the specific failure modes rather than gesturing vaguely at "AI security risk."

Tool overexposure is the most common practical issue: an MCP server that exposes every capability of the underlying system it wraps, rather than the narrow subset a given agent actually needs, hands any agent calling it a far bigger blast radius than its task requires. This is the same over-permissioning problem that shows up in any system granting programmatic access, just with an added wrinkle — the thing deciding when to use that access is a model making its own judgment call, not a human following a runbook.

Context window limitations are a subtler, less obviously "security" issue that becomes one in practice: as an agent connects to more MCP servers, the descriptions of every available tool compete for space in the same context window the model uses to reason about the actual task. An agent juggling tool descriptions from a dozen overlapping MCP servers is more prone to calling the wrong tool, or misreading what a tool actually does, than one with a small, well-curated set — which turns "how many MCP servers should this agent have access to" into a real design decision, not a maximize-capability default.

Open governance is the structural issue underneath both of the above. There is no central authority vetting every MCP server's security posture before it's published, and the gap between the curated official registry (9,652 servers) and the much larger universe of community GitHub repositories (15,926) is exactly where that shows up in practice — a server pulled from an unreviewed GitHub repository is a supply-chain risk in the same category as any other third-party dependency with write access to internal systems, not merely a code-quality concern to be caught in review.

None of this means MCP is unsafe to adopt — it means MCP's security properties are largely a function of how carefully an organization deploys it, not an inherent guarantee baked into the protocol itself. Treating every new MCP server the way a security-conscious team would treat any other new privileged integration — provenance-checking the source, scoping its credentials to the narrowest access the task requires, and logging every call it makes — closes most of the realistic gap. Our compliance resources cover the broader governance patterns this kind of access review sits inside for regulated or audit-sensitive organizations.

Where MCP Goes From Here, and How to Actually Adopt It

The Model Context Protocol Blog's own 2026 roadmap names four priorities: transport scalability (making remote, multi-tenant MCP deployments genuinely robust, not just functional), agent-to-agent communication (the A2A work described above), governance maturation (closing exactly the open-governance gap described in the previous section), and general enterprise readiness. Read together, those four priorities describe a protocol that knows it has already won the awareness battle and is now doing the less glamorous work of becoming boring, reliable infrastructure — which, for anyone who has watched a technology standard mature, is usually the correct next phase and not a sign of stalling momentum.

For a business actually deciding how to approach MCP rather than just tracking its growth curve, the practical path is narrower and more disciplined than "adopt everywhere." Start with one well-scoped integration — a single internal system, exposed through a single MCP server, used by one team's agent project — rather than treating MCP adoption as an enterprise-wide initiative from day one. Treat registry provenance as a real vetting signal when evaluating third-party MCP servers, not a formality: a server in the official registry has cleared a materially different bar than one pulled from an arbitrary GitHub repository. And loop security review in before connecting any MCP server to a system with write access or sensitive data, not after an agent has already been calling it in production for a quarter.

It's also worth resisting the temptation to standardize an entire organization's integration strategy on MCP purely because the ecosystem numbers are impressive. The protocol solves a specific problem — many AI applications needing consistent, reusable access to many tools and data sources — and it solves that problem well. A business with one agent talking to one system doesn't have the M×N problem yet, and forcing an MCP layer onto that simple case adds a dependency and a maintenance surface without a corresponding benefit. The right test is whether the integration need is actually going to multiply — more agents, more systems, more teams building on the same connectors — not whether the technology is currently the most talked-about one in the ecosystem.

That kind of protocol-level architectural judgment — deciding where MCP genuinely earns its cost versus where a narrower, purpose-built integration is the better call — is exactly the kind of decision that benefits from experience across multiple agent builds rather than a single team's first attempt at it. If you're scoping enterprise AI agent integrations and want that judgment applied from the outset rather than retrofitted after a security review flags it, that's core to the AI agents and automation work we do at Scult.

Straight Answers on MCP Adoption, Security, and the Road Ahead

What is the Model Context Protocol (MCP)?

MCP is an open specification, originally authored by Anthropic, that standardizes how AI models and agents connect to external tools, data sources, and systems. Instead of every AI application writing custom integration code for every tool it needs, and every tool writing custom integration code for every AI application that wants to use it — the combinatorial "M×N" problem — a system exposes its capabilities through a single MCP server, and any MCP-compatible AI client can discover and call them the same way. It functions as a shared connector layer sitting between AI applications and the real systems they need to reach. For an enterprise, the practical benefit is that integration work gets done once per system rather than once per AI project — a knowledge base or ticketing system exposed as an MCP server can be reused by every future agent a company builds, instead of each new agent project rebuilding the same connector from scratch. For a plain-language definition alongside other AI infrastructure terms, see our glossary.

How many MCP servers exist in 2026?

Two different counts are worth knowing, because they measure different things. As of a May 24, 2026 snapshot, the official MCP Registry listed 9,652 servers — a curated, discoverable index. A separate count of GitHub repositories tagged as MCP servers found 15,926, a broader figure that includes personal projects, experiments, forks, and prototypes that haven't been submitted to the official registry. The gap between the two is normal for a fast-growing open ecosystem: a smaller curated center surrounded by a larger, messier periphery of community activity, rather than a discrepancy that needs resolving. For anyone evaluating third-party servers, that distinction is a practical starting filter — registry presence signals discoverability and a lighter review pass, while a server that only exists as an unlisted GitHub repository deserves its own independent check before it touches anything sensitive.

Is the 78% enterprise MCP adoption claim reliable?

Treat it with caution rather than treating it as settled fact. The 78%-of-enterprise-AI-teams figure comes from andrew.ooo's "MCP Enterprise Adoption: The July 2026 State of Play," alongside a companion claim that 28% of Fortune 500 companies run MCP servers — both numbers that have drawn scrutiny over methodology and reliability in subsequent coverage. A more conservative, survey-grounded figure worth weighing against it is Stacklok's 2026 finding that 41% of enterprises report MCP use in limited or broad production, which paints a real but more measured adoption picture. When a headline adoption percentage circulates without a clear methodology attached, it's reasonable to anchor on the more conservative, survey-based number instead.

Which major AI products support MCP?

OpenAI, Google, Microsoft, and Salesforce all shipped MCP support across their own AI platforms within roughly 13 months of one another — direct competitors converging on a shared integration layer none of them individually controls. That kind of cross-vendor convergence, happening this quickly, is a stronger signal of durable standardization than any single vendor's adoption announcement would be, because it means every major player independently concluded that a shared protocol was cheaper than maintaining their own proprietary one. For a buyer evaluating AI platforms, that convergence is also a practical hedge against lock-in: an organization building agent integrations against MCP-compatible tooling isn't betting its integration work on a single provider staying dominant, since the same connectors are expected to keep working if the underlying model provider changes.

How is MCP different from function calling?

Function calling is the capability — a model deciding, mid-task, to invoke a specific function with specific arguments, which the surrounding application then executes. MCP is the protocol for exposing and discovering the tools available to call, standardized enough that one integration works across many different AI applications and frameworks instead of being rebuilt separately for each one. Function calling makes agents possible in principle; MCP is what stops every team from re-solving the same tool-integration problem from scratch. Put another way: a team choosing to support function calling is deciding their model can take actions at all; a team choosing to support MCP on top of that is deciding those actions should be reachable through a connector any other MCP-compatible application can also use, rather than a one-off wired specifically to their own product.

Is Streamable HTTP the current remote MCP transport?

Yes. Early MCP implementations relied on local process communication, well-suited to a developer running tools on their own machine, and an interim HTTP-plus-server-sent-events pattern for early remote use. Streamable HTTP has since become the standard transport for remote, network-deployed MCP servers — a detail that matters because transport scalability is explicitly named as one of the protocol's own priorities on its 2026 roadmap, and a protocol that only works well on localhost can't function as real enterprise infrastructure. In practice, this is the transport an enterprise team should expect to standardize on for any MCP server meant to be reached by more than one application or team, rather than treating the earlier local-only pattern as a viable production shortcut.

Are there verified statistics on MCP use in marketing automation?

Not a distinct, verified figure specific to marketing automation beyond the broader enterprise adoption numbers already covered — the research behind this piece didn't surface a marketing-automation-specific MCP statistic separate from the general registry size, SDK download counts, and production-adoption rate. That said, marketing and CRM tool connections are a plausible, commonly-cited use category for MCP servers in principle, since they're exactly the kind of external system (contact records, campaign data, analytics dashboards) that agentic workflows frequently need to reach — it's reasonable to expect dedicated statistics here as the ecosystem matures, just not something confirmed yet. Until a verified figure exists, the more defensible approach is to reason from the general production-adoption numbers already covered — the 41% limited-or-broad-production finding — rather than quoting a category-specific percentage that hasn't actually been substantiated.

What should teams do before adopting MCP in production?

Vet the provenance of any MCP server before connecting it to a real system — a listing in the official registry has cleared a different bar than an arbitrary GitHub repository. Scope credentials to the narrowest access the specific task actually needs, rather than granting broad system access "in case it's useful later." Log every tool call an agent makes through an MCP server, not just its final output, so an incorrect action can actually be investigated afterward. And loop in security and compliance review before production, not after — the same governance pattern applies whether the integration touching sensitive data happens to involve AI or not.

Does our organization need the MCP protocol at all?

It's a legitimate question, not a sign of falling behind — Chinese enterprise buyers are reported to be asking exactly this in a 2026 market guide, and the honest answer depends on how many separate AI-to-tool integrations an organization actually needs to maintain. A team with one agent talking to one or two internal systems may not need a standardized protocol layer at all; a purpose-built integration is simpler. MCP earns its cost once multiple agents, built by different teams or on different frameworks, need to reach a growing, overlapping set of tools and data sources — at that point, solving the integration problem once per system, rather than once per agent-system pair, starts paying for itself quickly.

How many companies actually run MCP in production versus just experimenting with it?

Stacklok's 2026 survey found 41% of enterprises report MCP use in limited or broad production — a real, substantial minority, but well short of universal deployment. Set against the ecosystem's much larger download and repository numbers, this is a coherent picture rather than a contradiction: a very large base of developer experimentation and internal tooling exploration, with a smaller but still meaningful share of that experimentation actually reaching production systems rather than staying in a sandbox. That gap between "developers are trying this" and "this runs against live systems" is normal for infrastructure this new, and it's worth checking which of the two a given adoption statistic is actually measuring before treating it as a production benchmark.

What's the difference between the official MCP registry and community MCP servers on GitHub?

The official MCP Registry (9,652 servers as of a May 24, 2026 snapshot) is a curated, discoverable index — closer to a package registry's featured listings. The broader count of MCP-tagged GitHub repositories (15,926) captures the full sprawl of the open ecosystem: personal projects, forks, experiments, and abandoned prototypes alongside genuinely production-ready servers that simply haven't been submitted yet. For procurement or security purposes, registry presence is a useful but limited trust signal — it indicates discoverability, not a security certification, so a server still needs its own provenance review regardless of which list it's on. A reasonable rule of thumb: treat registry inclusion as one input into a vetting decision, alongside who maintains the server, how actively it's updated, and how narrowly its declared tool set matches what your use case actually requires.

Will MCP become a mandatory feature of API gateways?

Not mandatory in a regulatory sense, but increasingly a competitive necessity. Gartner forecasts that 75% of API gateway vendors will have MCP capability by the end of 2026, which signals that MCP is being absorbed into general-purpose infrastructure — the same category as authentication and rate limiting — rather than staying a bespoke, AI-team-specific concern. A gateway vendor without MCP support in that environment isn't violating a rule, but is negotiating from a weaker position whenever a buyer's procurement checklist includes it. This pattern mirrors how earlier infrastructure standards matured — a capability starts as a differentiator a handful of vendors offer, then becomes an expected baseline once enough buyers ask for it by name, and the vendors slower to add it end up playing catch-up on a feature that no longer wins them any deals, only avoids losing some.

What's on the MCP roadmap after 2026?

The Model Context Protocol Blog's 2026 roadmap names four priorities: transport scalability (making remote, multi-tenant deployments more robust), agent-to-agent communication (the complementary A2A effort standardizing how separate agents coordinate with each other, distinct from MCP's agent-to-tool focus), governance maturation (closing the open-governance gaps around server vetting and security review), and broader enterprise readiness. Together, they describe a protocol moving from "widely adopted" to "reliably boring infrastructure" — the same maturation path most durable technology standards eventually follow. None of the four priorities describe adding flashy new core capability to the spec itself, which is itself a signal: the roadmap reads like an infrastructure team's punch list for handling real production load and real security review, not a features roadmap trying to win over skeptics who haven't adopted it yet.

Is MCP secure enough for sensitive enterprise data access?

Security here is largely a property of deployment discipline, not a fixed guarantee built into the protocol. The real risks worth naming are tool overexposure (a server exposing more capability than a given agent's task requires), context window limitations (too many competing tool descriptions increasing the odds of an agent calling the wrong one), and open governance (no central authority vetting every published server's security posture before other teams start relying on it). None of these make MCP unsuitable for sensitive data — they make provenance-checking, narrow credential scoping, and call-level logging non-negotiable before any MCP server touches production systems, the same discipline any new privileged integration deserves regardless of whether "AI" is involved.