MCP Ecosystem H1 2026 Retrospective: Adoption Data Points

The MCP ecosystem in H1 2026 crossed the line from open spec to operational standard. Server count tracked across npm and GitHub passed roughly 2,000, five major host surfaces 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, but Cursor, Codex CLI, and Windsurf shipped production-grade MCP support that closed the cross-host portability gap. 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 npm registry snapshots, host-side documentation, and the public MCP server directories. 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.

The first half 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, SSE or streamable HTTP for remote — 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 npm registry's keyword-tagged MCP servers, the public GitHub MCP server directories maintained by the community, and a small set of vendor-curated catalogues, the tracked server count crossed roughly 2,000 distinct MCP servers during Q2 2026 — up from around 1,200 at the end of 2025. That is a two-thirds increase 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, and through H1 2026 the host side moved from "Claude Desktop plus a few experimental adopters" to a mature five-surface landscape. The matrix below is the practitioner's view — what each host is best at, how it consumes MCP, and where it sits in a realistic 2026 stack.

The fifth surface that matters but does not fit the matrix cleanly is the long tail of bespoke agents — internal company-built agents, vertical SaaS agent features, and custom in-product copilots — that consumed MCP servers through the client side of the same SDKs. Treat host coverage as a five-major-plus-long-tail picture, not a five-surface ceiling.

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.

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 npm registry plus community-maintained lists work fine at 2,000 servers; they will be noticeably less fine at 10,000. H2 will likely see one or more vendor-curated catalogues, an attempt at trust-and-safety signalling per server, 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 3,500 – 4,500 tracked servers 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 five — expect at least one major IDE not listed above to ship first-class MCP, 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 emerges as a credible discovery surface. Today the community GitHub-list pattern works; at 5,000 servers it will not. The question is whether the catalogue ships from a vendor with ecosystem credibility or from the community itself.
• Machine-readable trust manifestsget 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 2,000-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.