MCP Ecosystem 2026: What the Adoption Numbers Actually Show

Model Context Protocol started as an internal Anthropic project in late 2024. It is now governed by the Linux Foundation and shipped by every major AI provider. If you are deciding whether to build on it, that trajectory matters more than any single download figure.

It matters because the figures in circulation are messy. The number you have most likely seen quoted for MCP — 97 million monthly SDK downloads — is real, but it is routinely misdated. It comes from the December 9, 2025 announcement that MCP joined the Agentic AI Foundation, not from spring 2026, and it has since been overtaken. The July 28, 2026 specification post puts Tier 1 SDKs at "close to half-a-billion downloads a month," with the TypeScript and Python SDKs each past a billion downloads in total.

What Effloow added#

Two things you will not find in the secondary coverage. First, a claim-to-source matrix: every widely-quoted MCP statistic checked against a primary source, with the ones that resolve to nothing marked as such. An uncited number is not a small problem when you are using it to justify an architecture decision.

Second, a census. Where a figure was missing but checkable, we went and counted it rather than leaving a gap — the official registry is a public read API, so the current server count and remote/local split are measured here on 2026-08-19, not quoted.

The bottom three rows are the ones worth noticing. Each is quoted constantly in MCP coverage, and none of them resolves to a publisher who will show you how the number was produced. Treat them as folklore until that changes.

MCP earned the adoption regardless, by solving a problem the industry had but had not coordinated around: the N × M integration burden. Before MCP, connecting models to tools meant a separate connector per model-tool pair. Five models against ten tools meant fifty integrations. MCP collapses that to fifteen, one implementation per side.

What follows traces the documented adoption milestones, a census of what is actually published to the official registry, and where the protocol is heading — with the sourcing shown so you can check it.

For MCP's sibling project under the same foundation, see our review of goose, Block's open-source agent framework. For what happens once agents start calling tools at volume, see our measured work on tool-call token cost.

The Problem MCP Solved#

Before understanding why MCP grew this fast, you need to understand the pain it removed.

Every LLM application that does anything useful needs to connect to the outside world. It needs to read files, query databases, call APIs, interact with services. Before MCP, the standard approach was function calling — each model provider defined their own schema for tools, their own way of passing context, their own format for responses. Claude used one schema. GPT-4 used another. Gemini had its own approach.

This created a compounding tax on developers. Every new model you wanted to support required rewriting your tool layer. Every new tool you built needed a separate implementation per model. Switching model providers meant rebuilding integrations from scratch.

The enterprise cost was even worse. Large organizations might have hundreds of internal tools and dozens of AI deployments. The maintenance burden was enormous, and the security surface area was invisible — nobody had a clear picture of what data each AI could access.

MCP addressed all of this with a single open specification:

• One protocol — JSON-RPC 2.0 over stdio (local) or Streamable HTTP (remote)
• One server spec — build a tool once, it works with any MCP-compatible model
• One client spec — implement MCP once in your model layer, connect to any tool
• Explicit permissions — what each server can access is defined in the manifest, not buried in code

The result was the "USB-C for AI" — a connector standard that made the integration problem boring in the best possible way.

The Adoption Timeline: Month by Month#

The growth of MCP is best understood as a series of inflection points, each triggered by a major player joining the ecosystem. Only two download totals have ever been published officially, in December 2025 and July 2026. The smooth month-by-month curve you see in secondary coverage fills the gap between them with numbers nobody has sourced.

November 2024: Launch#

Anthropic published the MCP specification and open-sourced official Python and TypeScript SDKs. Claude Desktop became the first MCP client.

The developer community's reaction was cautious but interested. The protocol made sense, the implementations were clean, but it was a single vendor's project. Most developers took a wait-and-see approach.

December 2024 – February 2025: Community Build-Out#

Early adopters started building servers. The GitHub repository for the official MCP servers launched with integrations for filesystem access, web search, GitHub, Slack, PostgreSQL, and a handful of other common tools. Third-party servers began appearing on GitHub.

Adoption in this window came mostly from hobbyists and early-stage AI startups experimenting with agentic workflows.

March 2025: OpenAI Joins#

The inflection point the ecosystem had been waiting for. On March 26, 2025, Sam Altman announced MCP support in the OpenAI Agents SDK, with the ChatGPT desktop app and Responses API to follow. Google DeepMind confirmed Gemini support the following month.

For developers, this was the signal that MCP was not going to be a proprietary Anthropic standard. If both Claude and ChatGPT supported it, building on MCP became a safe bet. The third-party server ecosystem accelerated sharply.

April – June 2025: The IDE Wave#

Cursor, Windsurf, and VS Code all shipped MCP client support within a few weeks of each other. JetBrains IDEs followed in May. For the first time, developers could use MCP servers directly from their editor — not just from chat applications.

This opened a new use case: using MCP as the integration layer for AI coding assistants. Instead of each IDE building its own database connector, GitHub integration, or documentation fetcher, they could all share the growing library of MCP servers.

July 2025: Microsoft and Copilot Studio#

Microsoft integrated MCP into Copilot Studio, giving enterprise developers a supported path to connect Microsoft 365, Azure services, and Dynamics 365 to AI workflows via MCP. Azure OpenAI also added native MCP client support.

This was the moment MCP became an enterprise conversation rather than just a developer one. IT departments that had been building custom integrations for Copilot started migrating to the MCP standard. Remote MCP server deployments began growing sharply — organizations wanted to run servers in their cloud infrastructure, not on developer laptops.

November 2025: AWS Joins#

AWS added MCP support across Bedrock, expanding the addressable market dramatically. Any organization using AWS for AI workloads could now connect Bedrock models to MCP servers without additional middleware.

More significantly, AWS's support brought MCP into environments with strict compliance requirements — healthcare, financial services, government. These sectors had been watching MCP's development carefully but waiting for cloud provider endorsement before committing. AWS's participation was that endorsement.

December 2025: Linux Foundation Governance#

Anthropic, Block, and OpenAI co-founded the Agentic AI Foundation (AAIF) under the Linux Foundation, transferring MCP governance to a neutral body. This addressed one of the last hesitations enterprise procurement teams had about adopting MCP: the risk of a single vendor controlling the specification.

With Linux Foundation governance, MCP joined the same class of infrastructure protocols as HTTP, OAuth, and gRPC — open standards with no single commercial owner.

December 2025: The 97 Million Figure, Correctly Dated#

This is the number most coverage attributes to spring 2026. It was published on December 9, 2025, in the AAIF announcement, which reported "over 97 million monthly SDK downloads, 10,000 active servers and first-class client support across major AI platforms like ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code and many more."

Two things follow. The 97M and 10,000-server figures are official, so you can cite them. But they describe December 2025, and anyone presenting them as the current state of the ecosystem is roughly eight months behind.

July 2026: Roughly Half a Billion Monthly Downloads#

The 2026-07-28 specification post is the most recent official figure at the time of writing: "close to half-a-billion downloads a month" across Tier 1 SDKs, with TypeScript and Python each crossing one billion cumulative downloads.

Download counts are the only ecosystem-wide figure MCP's maintainers publish. Client totals and developer-survey percentages circulate alongside them without an equivalent source. The one adjacent number you can check yourself is the registry, and the next section does exactly that.

Who Is Using MCP in 2026?#

Adoption data reveals a clear pattern: engineers are driving MCP growth from the bottom up, and enterprises are following.

Developer Adoption by Role#

The server categories that dominate public registries are overwhelmingly engineering tools rather than general business software, which tells you where the demand is concentrated. The recurring use cases:

1. AI coding assistance — connecting IDEs to documentation, GitHub, code search
2. Database access — letting AI agents query production and staging databases with defined permissions
3. CI/CD integration — Jira, Linear, GitHub Actions, Kubernetes status checks
4. Observability — Datadog, Grafana, PagerDuty integrations for incident response
5. Data pipelines — connecting AI workflows to dbt, Airflow, Snowflake

Enterprise Deployment Patterns#

Enterprise adoption tends to follow a different pattern from individual developer adoption. Rather than installing community servers, enterprises typically:

• Build private MCP servers for internal tools and proprietary data sources
• Deploy remote servers on internal infrastructure with SSO and audit logging
• Use gateway layers (Zuplo, Kong, AWS API Gateway) to manage MCP traffic, rate limiting, and security

Block, Bloomberg, AWS, Google, Microsoft, and Cloudflare are all named backers of the Agentic AI Foundation in the Linux Foundation announcement. Companies of that size do not put their name and their engineers on a foundation board over a protocol they are not already running internally, which makes the membership list a better enterprise-adoption signal than any of the Fortune 500 percentages in circulation. Those percentages have no published methodology behind them.

The "Shadow IT" Problem#

The rapid grassroots adoption of MCP has also created governance challenges. Security firm Qualys has documented a new class of risk in MCP Servers: The New Shadow IT for AI in 2026: servers that bind to localhost, take a random port, hide behind a proxy, or ship inside an IDE plugin, and so never appear in any asset inventory. Qualys names three patterns worth checking your own estate against — capability discovery used as reconnaissance, tool invocation as an execution surface, and supply-chain exposure through fast-moving SDKs.

This parallels the SaaS shadow IT wave of the 2010s. The solution is the same: visibility, policy, and governance tooling. Several security-focused MCP gateway products have emerged specifically to address this, offering centralized MCP server discovery, permission auditing, and access controls.

The Server Ecosystem: A Census of the Official Registry#

The last official server count is the "10,000 active servers" in the December 2025 announcement. Nothing has replaced it. But the official MCP Registry is a public, unauthenticated read API, which means the current number is not a matter of opinion — you can count it.

We did, on 2026-08-19, paging the whole registry and keeping only the current version of each server:

python3 scripts/mcp-registry-census.py \
  --out data/lab-runs/mcp-ecosystem-growth-100-million-installs-2026.registry.json
# 227 pages, 22,658 latest-version entries returned

Two things fall out of this that no secondary source will tell you.

The server count has roughly doubled since the last official figure. 22,408 active against 10,000 reported in December 2025 is 2.2x in about eight months. If you have been quoting "10,000 MCP servers" in a deck this year, the figure was accurate when it was published and is now off by more than half.

Read it with the concentration caveat, though. A single publisher, io.github.pipeworx-io, accounts for 1,312 entries — 5.9% of the entire registry on its own. The top fifteen namespaces together hold 14.9%. Registry entries are cheap to create and bulk publishing is not against the rules, so treat "number of servers" as a measure of publishing activity rather than of how many distinct, maintained integrations exist. The registry verifies that a namespace belongs to its publisher. It does not verify that anyone uses what was published.

For what developers actually reach for, the categories below are the recurring ones. This is a map of the space, not a ranking — the registry publishes no install counts, so anyone presenting a "most installed" list is ranking on something they have not shown you.

Developer & DevOps Tools

• GitHub — code search, PR management, issue tracking
• Docker Hub — container management, image search
• Kubernetes — cluster status, deployment management
• Jira / Linear — ticket management and project tracking
• Datadog / Grafana — metrics and observability

Data & Databases

• PostgreSQL / MySQL / SQLite — direct database querying with schema inspection
• Snowflake / BigQuery — cloud data warehouse access
• dbt — data model documentation and query generation

Productivity & Collaboration

• Slack — message search, channel management, notifications
• Notion — knowledge base access and page creation
• Google Workspace — Docs, Sheets, Drive, Calendar, Gmail
• Microsoft 365 — SharePoint, Teams, Outlook

Marketing & Analytics

• HubSpot — CRM access, contact and deal management
• Salesforce — enterprise CRM with full object access
• Google Analytics / GA4 — web analytics queries
• Ahrefs / Semrush — SEO data and keyword research

AI & LLM Tools

• Anthropic Claude — meta-MCP for Claude-in-Claude workflows
• OpenAI — GPT model API access as an MCP tool
• Pinecone / Weaviate — vector database access for RAG workflows

The Remote Server Shift#

The move from local stdio servers to remote HTTP servers is the ecosystem's most consequential trend, and the census puts a number on it: 52.9% of active registry entries now expose a remote endpoint, and 47.7% offer only a remote endpoint with nothing to install locally. Remote is no longer the advanced option. It is the majority shape.

Within those remote declarations, the transport question is settled:

Streamable HTTP replaced the older HTTP+SSE transport in the 2025-03-26 revision, and nine of every ten remote servers have since moved. If you are writing a client, SSE is still worth supporting for the tail, but it is a compatibility shim now rather than a path anyone is building on.

The packaging split tells the same story about languages that the SDK download figures do:

TypeScript and Python are 86% of everything published with an installable artifact, which is why those two are the SDKs with a billion cumulative downloads each and the rest are not close.

The reason remote wins is operational rather than ideological: local stdio servers run as child processes on the developer's machine and die when the session ends. Remote HTTP servers can be shared across a team, persist between sessions, handle authentication centrally, and scale independently of the client.

For enterprises, remote servers are not optional — they are the only viable architecture. A remote MCP server sitting in front of a database can enforce row-level security, log every query, rotate credentials, and be updated without touching client configurations. A local stdio server cannot.

The Protocol Itself: What Changed in 18 Months#

The MCP specification has matured significantly since the initial November 2024 release.

Specification Version 2025-11-25#

The 2025-11-25 revision was the last of the handshake-based specifications, and it is what most servers in production still speak. What it and the 2025-03-26 revision before it added over the initial draft:

• Streamable HTTP transport — arrived in 2025-03-26 and carried forward here, replacing the older HTTP+SSE transport with a single-endpoint design that survives load balancers and corporate proxies
• OAuth 2.1 integration — standardized authentication flow for remote servers, with PKCE and dynamic client registration
• Structured output — servers can define typed response schemas, not just text blobs
• Server-sent progress — long-running operations can stream progress updates to the client
• Elicitation — servers can request additional information from users mid-operation, enabling multi-step workflows

Specification Version 2026-07-28#

The 2026-07-28 specification is the significant one for anyone running MCP in production, because it re-architects the protocol around stateless operation. Its own "Key Details" section now opens by describing the base protocol as "stateless, self-contained requests" with "per-request capability negotiation," which is about as blunt a statement of intent as a spec makes. The changes:

• Stateless transport — the initialize/initialized handshake and the Mcp-Session-Id header are gone, so any request can land on any server instance behind an ordinary load balancer
• Multi round-trip requests (MRTR) — replaces server-initiated requests that needed a held-open stream, so a tool can ask the user for input mid-operation without a persistent connection
• Header-based routing — Mcp-Method and Mcp-Name HTTP headers let gateways and firewalls route and authorize without parsing the JSON body
• Cacheable list results — list and read responses carry ttlMs and cacheScope for client-side caching
• Authorization changes — RFC 9207 issuer validation, a move away from Dynamic Client Registration toward Client ID Metadata Documents, and issuer-bound credentials
• Extensions framework — tasks and similar features become formal extensions rather than core protocol

Read together, these say MCP has entered its infrastructure-maturity phase. The work is no longer about adding capability; it is about surviving load balancers, corporate proxies, and security review. If you built against the session-based model, the stateless migration is the change to plan for.

Stateless migration checklist#

Run this against any MCP server you already operate. Each item maps to one change in the 2026-07-28 specification, and each one is a thing that breaks quietly rather than loudly — the server keeps answering, it just answers wrong once traffic spreads across more than one instance.

The last two are the ones to escalate. Transport problems announce themselves in a staging environment; an authorization gap does not.

MCP vs. Competing Approaches#

MCP's dominance is real, but it is worth understanding what it beat out and what still competes.

OpenAI Function Calling#

Function calling (now called "tools" in the OpenAI API) predates MCP and is still widely used for simple, single-model applications. The key difference: function definitions are defined per-API-call, inline with the prompt. There is no concept of a persistent server, no discovery mechanism, no transport standard.

For applications that use a single model and have simple tool needs, function calling remains appropriate. For anything multi-model, multi-agent, or with persistent tool state, MCP is the better choice. If you are still at the point of writing those inline definitions by hand, our function calling schema builder generates the JSON Schema for OpenAI and Anthropic tool blocks in the browser.

Google A2A Protocol#

Google introduced the Agent-to-Agent (A2A) protocol in April 2025 alongside MCP support in Gemini. A2A focuses specifically on agent-to-agent communication — how one AI agent delegates work to another. MCP focuses on agent-to-tool communication — how an agent uses a capability.

The two protocols are complementary rather than competing. A2A handles the "how do agents collaborate" question; MCP handles the "how do agents connect to tools" question. Expect both to remain relevant as multi-agent systems mature.

Proprietary Enterprise AI Platforms#

ServiceNow, Salesforce Einstein, and similar enterprise AI platforms have their own integration layers that compete with MCP in their respective ecosystems. These platforms offer MCP compatibility as a bridge, but their native integrations go deeper into their own product surfaces.

For organizations that are heavily invested in a single enterprise platform, the platform's native AI integration may be superior. For organizations that want model flexibility or are building cross-platform workflows, MCP is the better foundation.

The Market Behind the Momentum#

The MCP ecosystem has spawned a new layer of commercial infrastructure:

• MCP registries and marketplaces — directories of verified, maintained MCP servers with installation metrics and security audits
• MCP gateways — proxy layers that add authentication, rate limiting, caching, and observability to MCP traffic
• MCP development platforms — tools for building, testing, and deploying MCP servers without managing infrastructure
• MCP security products — server discovery, permission auditing, and compliance tooling

Dollar-sized projections for this layer are easy to find and impossible to check. The "$10.4 billion by 2026 at 24.7% CAGR" figure that anchors much of the coverage has no inspectable methodology behind it, and a market sizing you cannot audit is not evidence of anything except that someone wanted a headline. The qualitative driver is not in dispute. As organizations move AI agents from experiments into production, they need tool integration that is reliable, secure, and auditable, and that is what this infrastructure layer sells.

What Comes Next: The Second Half of 2026#

Several developments are likely to shape the MCP ecosystem through the end of 2026:

Stateless migration — The 2026-07-28 rewrite gives operators something they have wanted since remote servers became the default: MCP traffic that behaves like ordinary HTTP behind ordinary infrastructure. Expect gateway and platform vendors to rebuild around it, and expect session-based deployments to need a migration path.

Enterprise registry consolidation — Today's fragmented registry ecosystem (multiple competing directories of MCP servers) is likely to consolidate around a handful of trusted, enterprise-audited sources. The Linux Foundation governance creates a path for an official canonical registry.

MCP as assumed knowledge — As the protocol settles into infrastructure, building an MCP server will be treated the way REST API design is treated now: a baseline skill rather than a differentiator, and something a job description mentions in passing rather than as a headline requirement.

Edge and embedded MCP — Lightweight MCP server implementations are emerging for edge compute environments, enabling AI workflows that can run on-device or at CDN edge nodes without full cloud infrastructure.

Getting Started with MCP in 2026#

If you haven't integrated MCP into your workflow yet, the barrier to entry is lower than it has ever been.

For individual developers:

1. Install Claude Desktop or Cursor (or any MCP-compatible client)
2. Search the official registry rather than a blog listicle — it is the one index where the namespace is proven to belong to the publisher
3. Add servers via your client's configuration — most clients use a JSON config file
4. Start with filesystem, GitHub, and your primary database driver

For teams:

1. Evaluate a remote MCP deployment for shared servers rather than per-developer local installs
2. Consider a gateway layer if you have compliance or audit requirements
3. Inventory what private tools your team uses most frequently — those are the highest-value candidates for MCP server development

For enterprises:

1. Treat MCP servers as internal APIs — apply the same security, documentation, and change management standards
2. Deploy a discovery mechanism so teams can find and reuse MCP servers that others have already built
3. Engage with the AAIF specification process to ensure your requirements are represented in future versions

When to Build on MCP, and When to Skip It#

Build on MCP when: you need the same tool reachable from more than one model or client; you want tool integrations to outlive the app that first needed them; you are in an enterprise setting where a remote server with central auth, audit logging, and row-level security is a requirement rather than a nicety; or you are shipping a developer-facing product and want to meet users inside the editor they already use.

Skip MCP when: you have a single model, a handful of tools, and no plan to change either — plain function calling is less machinery for the same result. Also skip it if your integration is a one-off script, or if you are committed to a single enterprise platform whose native integrations reach deeper into its own surfaces than an MCP bridge will.

Build remote, not local. Nearly half the registry now ships a remote endpoint and nothing else, and the specification was rewritten to make that shape work behind ordinary load balancers. A local stdio server is the right call for a personal tool on one machine. For anything a second person will touch, you are building the minority shape and inheriting the migration.

The caveat on timing: the protocol changed shape in July 2026. Target the stateless 2026-07-28 specification. Most tutorials you will find were written during the first eighteen months and teach the session-based model, so check the date on anything you copy.

Summary#

MCP went from a November 2024 announcement to an officially reported 97 million monthly SDK downloads by December 2025, and to roughly half a billion a month by July 2026. The growth was not luck. It was a sequence of adoption decisions by the industry's largest players: OpenAI in March 2025, Microsoft in July 2025, AWS in November 2025, and Linux Foundation governance in December 2025.

Each of these moments addressed a specific hesitation. OpenAI's adoption proved it wasn't a proprietary lock-in. Microsoft's integration made it enterprise-credible. AWS's support satisfied compliance teams. Linux Foundation governance removed the single-vendor governance risk.

The result is a protocol that has achieved something rare in infrastructure: genuine consensus. In a world where AI providers compete fiercely for developer adoption, MCP is the standard they all agreed to ship.

That consensus is worth paying attention to. When every major AI provider implements the same protocol, building on top of it becomes a safe architectural bet — close to the safest available in AI tooling right now.

What the numbers cannot tell you is the part that actually decides your project. The registry has 22,408 active servers and publishes no install counts, so the ecosystem's size says nothing about whether the specific integration you need is maintained. Check the one server you depend on. The aggregate is context, not an answer.

Primary Sources#

1. MCP joins the Agentic AI Foundation — Model Context Protocol Blog, December 9, 2025. Source for the 97M monthly downloads and ~10,000 active servers figures.
2. The 2026-07-28 Specification — Model Context Protocol Blog, July 28, 2026. Source for the stateless architecture changes and the ~500M monthly / 1B cumulative download figures.
3. Linux Foundation Announces the Formation of the Agentic AI Foundation — Linux Foundation press release, December 2025. Source for founding projects and platinum members.
4. Sam Altman on OpenAI MCP support — March 26, 2025. Source for the OpenAI adoption date and initial scope.
5. MCP specification, 2026-07-28 — the normative text. Source for "stateless, self-contained requests," per-request capability negotiation, and the extensions framework.
6. Official MCP Registry API — the public read endpoint the census pages. Source for every server-count, transport, and packaging figure above.
7. modelcontextprotocol/registry — registry source and publishing rules. Source for namespace-ownership verification and the registry's preview status.
8. MCP transports, 2025-03-26 revision — the revision that introduced Streamable HTTP and deprecated HTTP+SSE.
9. MCP Servers: The New Shadow IT for AI in 2026 — Qualys, March 2026. Source for the shadow-IT risk patterns.

MCP's download numbers roughly quintupled between the two official data points, which are less than eight months apart. Before you put any figure from here into a slide, re-check it against source 2. That is where the next one will appear.

Related reading: our review of goose, the AAIF founding project that ships MCP integration natively; our comparison of AI agent frameworks; and our measured proof runs on tool-call token cost and tool failure recovery.