The MCP Ecosystem Is Growing Fast — and Quietly Becoming a Directory of Hosted Services

We recently measured whether the servers in the official MCP registry actually run (short version: 84% are remote-only, and under half of the installable ones boot clean). While that data was in front of us, a different question fell out of the same snapshot: not "do they work," but "where is this going." The registry stamps every server with a publishedAt date, so you can watch the ecosystem grow month by month. The trend is sharp enough to be worth a short note.

The numbers

From our snapshot of the registry, grouping each server by the quarter it was published and by whether it ships an installable package (npm/PyPI) or is a hosted remote endpoint:

                 new servers     remote (hosted)   local (installable)
  Q1 2026             56               43                  13
  Q2 2026            202              167                  35

Two things, both clean:

• The registry's intake nearly quadrupled — 3.6× from Q1 to Q2 2026 (56 → 202 new servers). Whatever else is true, MCP adoption by publishers is accelerating fast.
• 82% of the Q2 additions are hosted remote endpoints, not packages you can npx. The thing growing isn't a catalog of local tools — it's a directory of services.

This isn't a reversal; remote servers led from the registry's first months. But the gap is widening as the volume climbs: the more the ecosystem grows, the more it grows hosted.

Why this is worth noticing

The default mental model of an MCP server — set by the early filesystem/git/sqlite reference servers — is "a small program you run locally that exposes some tools over stdio." That model is now the minority case and shrinking as a share. What's actually being published, at an accelerating rate, is companies standing up a hosted MCP endpoint in front of their existing product: a URL your agent connects to, not code that runs on your machine.

That shift changes the questions you should ask before adding a server, and most of them get harder, not easier:

• A local server is code you audit once; a remote server is a dependency on someone else's uptime, versioning, and trust, forever. When the filesystem server changes, you pulled the change. When a hosted server changes its tool behavior, it just changed — mid-session, with no diff.
• Your context and prompts leave your machine. A remote MCP server sees the inputs your agent sends it. That's a data-flow decision you're making every time you wire one in, and the registry listing doesn't surface it.
• The boot-funnel reliability problem is replaced, not solved. Hosted servers don't fail to npm install — they fail with a 503, a rate limit, or a silent behavior change. The failure modes move from "won't start on my laptop" to "flaky third-party service in my agent's critical path."

None of that is an argument against hosted MCP servers — they're often the only practical way to expose a real SaaS to an agent, and "no install" is a genuine win. It's an argument for noticing the trend and updating your defaults. If you're building tooling, infrastructure, or policy around "MCP server = local stdio process," the ground is moving under that assumption at 3.6× a quarter.

The honest caveats

This is a snapshot, not a census. We pulled a few hundred unique latest servers from the registry, not necessarily every entry, so treat the absolute counts as a sample and the ratio and trend as the signal — and those are stable across the slice. publishedAt is the date a server was published to the registry (which itself launched in late 2025), not when the project was created, so this measures registry adoption, not the birth of MCP servers in the wild. The remote-vs-local split is read from whether a server lists packages (installable) or only remotes (hosted). Anyone can reproduce it: pull registry.modelcontextprotocol.io/v0/servers, bucket by publishedAt and packaging.

The one-line takeaway: MCP is winning, fast — and it's winning as a network of hosted services, not a package manager of local tools. Plan your agent architecture for the ecosystem that's actually being built, not the one the first five reference servers implied.

→ Talk to us if you're deciding how much of your agent stack should depend on third-party hosted MCP endpoints.

---

Reproducible from a single registry pull (June 2026); counts are a sample of the registry, the ratio and the Q1→Q2 growth are the durable signal. Companion to our boot-funnel measurement (does a server run); this one is about where the ecosystem is heading (what's being published).