MCP Ecosystem H1 2026 Retrospective: Adoption Data Points

The MCP ecosystem in H1 2026 crossed the line from open spec to operational standard. Public-registry coverage tracked across PulseMCP, the official MCP registry, Smithery, and mcp.so crossed roughly 9,400 distinct servers by mid-April 2026, five Anthropic-and-OpenAI-native host surfaces (plus VS Code with GitHub Copilot agent mode as a sixth canonical surface) shipped first-class integrations, and the tool-category taxonomy that emerged during 2025 stabilised around five durable buckets. What was a curiosity in late 2024 became the contract every tool-using agent stack now plans against.

Three trends drove the curve. First, host coverage matured — Claude Desktop and Claude Code stayed the reference implementations, while Codex CLI, Cursor, and Windsurf — all of which shipped MCP support during 2025 — matured their MCP integrations through H1 2026 with OAuth, remote-server, and cross-host parity work. Second, enterprise auth and governance arrived as table-stakes rather than research projects, with OAuth-bound remote servers, scoped permissioning, and audit trails becoming expected. Third, distribution discipline professionalised — npm scopes, semver, CI smoke-tests, and README contracts replaced the prototype-grade publishing of 2024.

This retrospective covers what the numbers actually say across those three vectors, with primary data sourced from the public MCP registries (PulseMCP, registry.modelcontextprotocol.io, Smithery, mcp.so), host-side documentation, and the npm registry. We close with a four-trend read-out for H2 and a projection that frames where the curve goes next. Where a number is a directional estimate rather than a precise count, we say so.

1. 01
   Public-registry server count crossing ~9,400 by mid-April 2026.PulseMCP, registry.modelcontextprotocol.io, Smithery, and mcp.so tracked ~9,400 distinct MCP servers by mid-April 2026, up from ~6,800 at year-end 2025 — roughly +38% growth in four months. Growth concentrated in connectors and developer tooling.
2. 02
   Host coverage maturing across five Anthropic-and-OpenAI-native surfaces plus VS Code/Copilot.Claude Desktop and Claude Code remain reference hosts; Cursor, Codex CLI, and Windsurf — all of which shipped MCP during 2025 — matured OAuth, remote-server, and cross-host parity work through H1 2026. VS Code with GitHub Copilot agent mode (GA July 2025) is a sixth canonical surface by the same four-criteria test. Cross-host portability is no longer aspirational.
3. 03
   Enterprise auth and governance arriving as table-stakes.OAuth-bound remote servers, scoped permissioning per workspace, and basic audit-log primitives moved from research patterns into the SDK and into vendor deployments through H1.
4. 04
   MCP-as-standard consolidating.The market converged on MCP as the default tool-calling contract; competing bespoke per-vendor formats lost share. Most new tool integrations now ship MCP first and proprietary formats second.
5. 05
   Tool category breakdown stabilising into five buckets.Connectors, developer tooling, data and search, system and browser control, and creative or content tooling — the working taxonomy that emerged during 2025 held through H1 2026 without major reshuffling.

The first part of 2026 is when MCP stopped being a thing that individual teams adopted as a bet and became the thing that teams assumed when scoping new agentic work. That shift is hard to date precisely — adoption is a curve, not an event — but the ecosystem behaviour through January, February, March, and April 2026 left little ambiguity about the direction.

The clearest signal was on the buyer side. Procurement conversations through Q1 began listing "MCP-compatible" as a checkbox for any tool that wanted to be integrated into an agent stack, the same way teams listed "OpenAPI" a decade earlier. Internal platform teams at mid-market and enterprise organisations started spinning up their first MCP servers — typically wrapping an internal corpus, an internal API, or a per-team workflow — rather than evaluating whether to use MCP at all.

On the supply side, the open-source pattern compounded. Each new MCP server made the next one cheaper to author: shared SDKs, shared scaffolding, shared CI templates, shared README conventions. The fixed cost of a new integration dropped to something close to the cost of writing the underlying business logic once. That is the same dynamic that made REST inevitable in its time, and the same dynamic that ended bespoke tool-calling formats in this one.

The other thing H1 settled is the geometry of the standard itself. The transport story stabilised — stdio for local, Streamable HTTP for remote (the legacy HTTP+SSE transport was deprecated in MCP spec 2025-03-26 and is fully superseded in the current 2025-11-25 spec) — and the JSON-RPC and JSON Schema substrate proved robust enough that very little protocol churn actually shipped through the half. Spec work continued on auth, on remote-server lifecycle, on session resumption, but the wire format that an MCP server author wrote against in January was the same wire format they wrote against in April. That stability, more than any single feature, is what unlocked enterprise engagement.

The headline number is the easiest one to verify and the most useful one to anchor on. Combining the four canonical public registries — PulseMCP, the official MCP registry, Smithery, and mcp.so — plus the npm registry's keyword-tagged MCP servers, the tracked server count crossed roughly 9,400 distinct MCP servers by mid-April 2026 — up from around 6,800 at year-end 2025 (see also Bloomberry's ecosystem analysis). That is roughly +38% in four months, a curve consistent with healthy compounding rather than a one-off spike.

Counting is harder than it looks. The same server can appear under multiple namespaces — a community fork of a vendor server, a wrapper that re-publishes another package with a thin preset — so any single number is a directional estimate. The cleaner view is the breakdown by category, which is where the ecosystem composition actually lives.

The remaining roughly 6% is the creative and content cluster — image generation wrappers, video editors, document and slide generators, design-system queriers, brand and asset libraries. Small in count, but disproportionately visible because the demos travel well on social channels and because agency teams adopt them early. Expect this cluster to expand through H2 as creative agents become a more common product pattern.

One pattern worth flagging: the connector cluster includes a growing proportion of vendor-published servers rather than community-built ones. Through 2025, most SaaS connectors were authored by independent developers or the agent vendors themselves; through H1 2026, the underlying SaaS vendors increasingly shipped their own first-party MCP servers, treating the protocol as a distribution channel for their API.

Host coverage is the variable that matters most to a server author. A protocol is only as useful as the hosts that actually consume it. By our four-criteria test — a documented config surface for registering MCP servers, support for both stdio and a remote transport, native UI for tool consent and tool-call results, and shipping on the stable release channel — five Anthropic-and-OpenAI-native surfaces meet the bar (Claude Desktop, Claude Code, Cursor, Codex CLI, Windsurf), and VS Code with GitHub Copilot agent mode (GA July 2025) clearly qualifies as a sixth canonical surface. The Anthropic-host monoculture had already broken before H1 2026 began — ChatGPT, VS Code/Copilot, Cursor, Windsurf, and Codex CLI all shipped MCP during 2025. By mid-May 2026, they had matured OAuth, remote-server, and cross-host parity. The matrix below is the practitioner's view of the five Anthropic-and-OpenAI-native surfaces; VS Code/Copilot is covered in the sidebar that follows.

The sixth canonical surface — not in the matrix above only because it sits on the Microsoft/GitHub side rather than the Anthropic-or-OpenAI side — is VS Code with GitHub Copilot agent mode. MCP support shipped in VS Code 1.99 in March 2025 and went GA in VS Code 1.102 in July 2025, meeting all four criteria (documented config surface, stdio + remote transport, native UI for tool consent, stable release channel). Beyond the six canonical surfaces, the long tail of bespoke agents — internal company-built agents, vertical SaaS agent features, and custom in-product copilots — also consumes MCP via the client SDKs. Treat host coverage as six canonical surfaces plus a wide long tail.

Cross-host portability is now the practical reality, not the aspirational claim. A server that ships with a clean Zod schema, structured error envelopes, and a published npm artifact will run unmodified across every surface above. The places teams still stumble are environmental — config file locations differ per host, env-var conventions vary, restart-after-config behaviour differs — not protocol-level.

The category breakdown shown in Section 02 was not pre-ordained. Through 2025 the community tried several taxonomies — by data sensitivity, by transport, by host affinity, by SaaS-vs-internal split. The five buckets that survived into H1 2026 — connectors, developer tooling, data and search, system and browser, creative and content — are the ones that map cleanly onto how product teams actually plan agent rollouts.

The pragmatic value of a stable taxonomy is that it makes security and governance reviews tractable. A platform team evaluating MCP rollout no longer has to grade each server in isolation; the category carries a default risk profile that scopes the review.

Methodology note on the percentages that follow: no public registry (PulseMCP, registry.modelcontextprotocol.io, Smithery, mcp.so) publishes this five-bucket category split. The figures below come from a Digital Applied ecosystem snapshot taken in April 2026 against our tracked subset of those registries, hand- classified by category. Treat them as directional ranges (Connectors ~35-40%, Dev tooling ~25-30%, Data & search ~15-20%, System & browser ~10-13%, Creative & content ~5-8%) rather than precise splits.

The fifth cluster, creative and content, lands lower on the risk ladder for most teams because the tools tend to be additive — generate an image, draft a slide deck, query a design system — rather than mutating. The governance focus there is less about access scoping and more about brand-fidelity guarantees and licence-clean output, which is a different problem class than the other four buckets handle.

One pattern that emerged across all five clusters in H1: the best servers ship not just a tool catalog but a clear statement of trust — what the server reads, what it writes, what side effects it can produce, and what failure modes a host or user should expect. That sort of machine-readable trust manifest is not in the spec yet, but mature server READMEs are doing it informally, and H2 will likely formalise it.

The single most important storyline of H1 2026 — and the one that determines whether MCP holds the standard position it now occupies — is enterprise readiness. Through 2025 the typical production deployment of MCP was a single user's machine, running stdio servers against APIs the user had personally authorised. That model does not scale to a company of two thousand people. The H1 work was almost entirely about closing that gap.

Three layers moved. Authentication on remote MCP servers converged on OAuth 2.1 patterns rather than ad-hoc bearer tokens — workspaces register an MCP server once, users authorise against their own credentials, scopes flow through cleanly. Governance primitives — per-workspace allowlists, per-user permission scoping, audit logs of every tool call — moved from research to commodity. And multi-tenant deployments shipped: a single MCP server instance serving many users with properly isolated data and identity.

The buyer-side story matches. Procurement and security teams began listing MCP as a requirement rather than a curiosity. Some specifically demanded MCP-compatible vendor APIs in renewal negotiations — a signal that the protocol has crossed from engineering preference into procurement gravity. Vendors that had previously hand-rolled tool-calling integration for individual AI surfaces started shipping a single MCP server instead and treating it as the canonical surface.

A practical caveat: enterprise readiness is not uniform across categories. Connector servers (SaaS wrappers) led the curve because OAuth was already their substrate. Data and search servers came next, with row-level security and audit-log passthrough. Developer tooling and system / browser servers lag on remote, multi-tenant deployment by design — those clusters are still mostly local-trust by intent, because the tooling is inherently scoped to the user's machine. That is not a gap so much as a category boundary.

For platform teams scoping their first MCP rollout, the practical sequence is to start with one connector category server (a SaaS wrapper your team already authenticates against), stand up the OAuth + audit-log pattern around it, and use that as the template for everything that follows. If that sequence sounds like the kind of work our team does with clients on production rollouts — it is, and our AI digital transformation engagements typically scope an MCP rollout as one of the first two workstreams.

Stepping back from the per-cluster detail, four trends sit above the noise. None of them are surprising in isolation; the value is in seeing them stack.

The trends interlock. Standard consolidation makes cross-host portability worth investing in; cross-host portability makes enterprise arrival possible; enterprise arrival pulls distribution discipline into shape; distribution discipline feeds back into standard consolidation by lowering the cost of the next integration. That feedback loop is the structural reason MCP's position is now hard to dislodge.

The trend that does not fit cleanly into the loop — and is therefore worth watching — is the discoverability story. The four canonical registries (PulseMCP, registry.modelcontextprotocol.io, Smithery, mcp.so) plus npm-keyword-tagged packages already cover ~9,400 servers; the question is whether discovery surfaces scale to 12,000+ with trust signalling intact. H2 will likely see one or more of these registries shipping per-server trust-and-safety signals and earlier spec work on machine-readable trust manifests. The teams that cannot find the right server will be the teams that build the wrong one.

Projecting from a four-month sample is intellectually cheap, so we will be honest about what is forecast versus what is extrapolation. Three things look near-certain through H2 2026; two things look likely but not guaranteed; one thing is a real risk that buyers should price in.

Near-certain through H2

• Server count continues to compound at a similar curve, plausibly reaching 10,000 – 12,000 tracked servers across major public registries (PulseMCP, registry.modelcontextprotocol.io, Smithery, mcp.so) by end of 2026. Growth concentrates in vendor-published connectors and enterprise-internal servers rather than community-published novelties.
• Host parity broadens beyond the current six canonical surfaces — expect at least one more major IDE or vendor-native agent to clear the four-criteria bar, plus continued maturation of in-product copilots consuming MCP via the client SDKs.
• Enterprise auth becomes default, not a feature. The OAuth 2.1 + audit + scoping pattern that stabilised in H1 ships as boilerplate; SDK helpers turn it into a few-line concern rather than a system to design from scratch.

Likely but not guaranteed

• A vendor-neutral server catalogue hardens as the default discovery surface. PulseMCP, the official MCP registry, Smithery, and mcp.so already cover the ~9,400-server landscape; the question for H2 is which of them ships per-server trust signalling, install attestation, and category-level governance hooks first.
• Machine-readable trust manifests get spec work. The informal "what this server reads, writes, and touches" statements in mature READMEs will likely formalise into a structured field — readable by hosts, consumable by governance tooling.

The real H2 risk

• Supply-chain incidents. A ~9,400-server ecosystem on npm with permissive install patterns is a target shape that the broader npm community already understands the hard way. One credible incident — a malicious or compromised MCP server reaching meaningful install volume — would accelerate the trust-manifest, allowlist, and catalogue work by months, but at the cost of buyer-side caution that lasts a year.

For teams building agentic products in H2, the practical implication is to lean into the standard now rather than wait for it to settle further — it has settled. The right place to spend caution is on the discovery and supply-chain side: pin versions, audit servers you depend on, prefer vendor-published servers for SaaS connectors where the vendor is the source of truth, and build a per-team allowlist before you build a per-team build-out. Our MCP server tutorial walks the build side end-to-end; our MCP server security audit walks the review side.

By May 2026, MCP had become the standard.