450+ MCP Servers Catalogued and Quality-Scored Daily: What the Ecosystem Census Says About the Tool Sprawl Your Deploy Platform Inherits

Somebody is keeping score on every MCP server on GitHub, every single day — and the class average is 16.3 out of 100. The mcp-ecosystem-scanner project crawls GitHub daily, validates each repository as a genuine Model Context Protocol server, and grades the whole set on documentation, tests, CI, maintenance activity, and community adoption. The September 18, 2026 scan catalogued 453 servers across 10 categories, and the headline number should sober up any platform team whose tenants are one mcp.json edit away from installing any of them.

If you run a deploy platform, an internal developer platform, or any fleet where agents touch production systems, this census is the closest thing you have to a standing answer for the question that actually matters: which of these servers do we bless for tenant agents, and which do we refuse to run at all? Here is what the numbers say, what the scanner cannot tell you, and how to turn both into an allowlist built from data instead of one-at-a-time audits.

The census in one table​

The September 18 scan (12:18 UTC) reports the following, and the count moves by a few servers in either direction every day — snapshots from earlier in September show 454 to 456, so treat any single figure as a dated reading, not a constant:

Read that table twice, because the second reading is the bleak one. The top of the distribution looks healthy: private-gpt, Microsoft's playwright-mcp, and a few others score around 90 with tens of thousands of stars each. But an average of 16.3 against a ceiling of 90 means the distribution is a cliff, not a bell curve — a thin maintained head over a very long tail of repos with no tests, no CI, no releases, and no recent commits.

The most damning signal is not in the table at all: stars do not predict quality. Both servers new this month carry over a thousand stars each and score zero. Microsoft's Azure DevOps MCP server, with 2,000 stars, scores zero. Cloudflare's MCP server scores zero, as do AWS's sample serverless MCP servers. These are first-party servers from the vendors hyperscaler customers trust most, and by every maintenance signal the scanner checks — tests, CI, releases, recent activity, issue health — they look identical to abandonware. Star count measures attention. The census measures upkeep. A deploy platform that confuses the two inherits the tail.

What the scanner actually measures (and what it doesn't)​

The score is transparent, which is exactly what makes it useful as policy input. Every server gets 0 to 100 from eight observable signals:

Reproducibility is the point: anyone can clone the repo, set a GitHub token, and re-run scanner.py plus dashboard.py to get the same numbers. No account, no vendor, no black box.

But audit the rubric the way you would audit any control, and the gap jumps out: not one of the eight signals is a security signal. Nothing checks whether the server requires authentication, whether it ships hardcoded secrets, whether its declared tools include shell execution or credential passthrough, whether its transport encrypts anything, or whether its dependencies carry known CVEs. The census answers "is this server maintained?" with unusual rigor and answers "is this server safe?" not at all. A score of 90 tells you the project has tests and cuts releases. It tells you nothing about what happens when you hand that server your production database credentials.

That is not a criticism of the scanner — it is explicit about what it measures, and maintenance hygiene genuinely predicts whether a security fix will ever land upstream. It is a warning about stopping there. The score is a necessary input to a bless decision, never a sufficient one.

Three sprawl signals a platform team should read​

Beyond the headline average, three structural readings in the census deserve a platform team's attention, because each one names a cost the platform inherits the moment it blesses third-party servers.

1. The transport split is legacy debt you adopt. Declared transports read stdio 247, sse 351, streamable-http 126, unknown 65 — sums exceed the server count because servers declare more than one. The shape still matters: SSE, the legacy remote transport the protocol has been moving away from since Streamable HTTP arrived, remains the most-declared remote transport by nearly three to one.

Every SSE-only server you bless is a server whose transport story is already on the wrong side of the protocol's direction of travel, including the stateless rewrite in the 2026-07-28 specification. Transport is not a cosmetic attribute; it determines how auth attaches, how sessions scale, and what your gateway has to support. Blessing the long tail means operating its transports.

2. The largest category is other. Of 453 catalogued servers, 162 — more than one in three — land in the catch-all bucket, dwarfing the next-largest category (ai-ml at 80; cloud has just 9). That is a discovery failure wearing a taxonomy costume. When a third of the ecosystem resists categorization, "browse the catalog and pick the good ones" stops working as a procurement motion long before you reach server 400. Manual curation does not scale to this shape; scored, filterable signals do. The scanner's own existence is the proof: it was built precisely because awesome-lists and the young official registry offer no automated way to separate maintained servers from abandoned ones.

3. Two languages own the supply chain, and the tail is already rotting. TypeScript (210) and Python (201) together account for more than nine in ten catalogued servers, with Go a distant third at 12. Concentration cuts both ways: your sandboxing and dependency-scanning story can cover the ecosystem by covering two runtimes well, but a vulnerability class in either runtime's MCP SDK or dependency tree lands on nearly every server at once. Meanwhile 18 servers are already archived or abandoned — roughly one in twenty-five — and the daily scan keeps finding them faster than anyone delists them. Without a freshness signal wired into your allowlist, abandoned servers do not age out. They sit in tenant configs until they become the incident.

One more piece of context keeps the census honest: it covers the GitHub-discoverable slice that validates as genuine servers. Registry-scale graders see a far bigger universe — Manifold scored 7,700 servers from the official registry in May, Canopii scored 11,524 in June, and the ecosystem had already passed 10,000 active public servers with 97 million monthly SDK downloads when Anthropic donated the protocol to the Agentic AI Foundation in December 2025. The census is a sample of the maintained core, and even the maintained core averages 16.3. The sprawl beyond it is graded worse, where it is graded at all.

The question the census can't answer​

"Which of these servers touches production credentials, and what stops it from abusing them?" Every number orbiting the census says this is where the real risk lives:

• 41% of servers in the official MCP registry shipped zero authentication as of February 2026, in a 518-server scan cited by OWASP's MCP security guidance — which lists shadow MCP servers as its own Top-10 category.
• More than 21,000 internet-facing MCP instances are currently exposed, with nearly 92% of audited production servers lacking basic OAuth, per data surfacing around the MCP Dev Summit in Seoul in August 2026.
• MCP-named CVE records more than doubled in 2026, from 23 in all of 2025 to 53 by September 13 — and keyword counts miss bugs described in other words, so treat that as a floor.
• Security-graded samples score as badly as maintenance-graded ones. Agentgraph's scanner found an average trust score of 25.8 out of 100 across 28 popular servers, with unsafe code-execution patterns in most of roughly 950 agent and MCP repos scanned — including popular, well-maintained projects.

The official registry, meanwhile, remains young and hands-off on grading: it provides publisher identity and distribution, not maintenance or security scores. That vacuum is exactly why a third-party layer now exists — JFrog's universal MCP registry as a governed system of record, Manifold's lineage-plus-safety scoring, Canopii's trust index, Cisco's and Snyk's scanners. The market has voted: nobody trusts an ungraded install anymore. Your allowlist should assume the same and demand graded evidence for every entry.

There is a second, quieter cost to ungoverned sprawl that belongs in the same decision: tokens. Multi-server MCP configurations routinely consume 40 to 50 percent of available context before any real work happens, and tool-selection accuracy in the same body of work fell from a 43 percent baseline to under 14 percent as tool count grew. Every server you bless is not just attack surface — it is context-window surface that makes every tenant agent measurably dumber. An allowlist is a quality control and a performance control at once.

From census to allowlist: a bless-or-block rubric​

Combine the census's maintenance signals with a security grader's output and you get a rubric a platform team can actually operate. Three tiers, evaluated per server version, refreshed on the scan's cadence — not once at procurement time:

Four operating notes make the rubric hold up in practice. First, pin versions, not projects: the daily scan exists because servers change under you, so a bless decision attaches to a release tag and expires into re-evaluation. Second, re-run on cadence: pull the census feed and your security scanner on the same schedule the data refreshes — daily for the census, per-release for scans. Third, cap the count: the token math above means the allowlist needs a size budget per tenant, not just per-server gates; ten blessed servers that eat half the context window are a performance incident with extra steps. Fourth, fail closed with reasons: when a tenant's config references a blocked server, the error should name the tier and the failing signal, so the path from "refused" to "blessed" is visible instead of tribal.

None of this requires auditing 453 servers by hand. It requires two automated feeds — the census for "is it maintained," a security grader for "is it safe" — and a gateway that enforces the join. That is the whole pitch of the census as infrastructure: it converts an unbounded manual review queue into a scored feed your policy engine can consume.

The census is infrastructure now​

Step back and the arc is familiar. Every protocol that goes from developer toy to enterprise dependency grows the same three layers: a registry for distribution, independent graders for trust, and policy enforcement at the platform edge. Package ecosystems learned this with npm audit and lockfiles; container ecosystems learned it with image scanning and admission controllers. MCP is learning it right now, in public, at the speed of a protocol that went from announcement to 10,000 public servers in barely a year.

The September census is the clearest artifact of that transition: maintenance grading, automated daily, free to consume. Use it as the standing freshness input to your allowlist, pair it with a security grader for the credential-touch question the census cannot answer, and enforce the result at the gateway where tenant configs meet production systems. The sprawl is not slowing down — but with scored feeds instead of vibes, it does not have to slow down for your platform to stay safe.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Blessed MCP servers deserve the same treatment as any other workload: versioned, observable, and running on infrastructure you control. Star the repo on GitHub or deploy your first app today.