I tried to start 182 MCP servers. 65 answered.

Every published count of the MCP ecosystem counts packages. None of them counts working software, because checking would mean starting the servers — so we built a harness that does: it connects on a schedule, asks each server to list its tools, and records every attempt.

Here is the first real batch. (We argued the counting problem at length in the previous post, which also admitted we had never checked either. This is that gap closed.)

Read the failures carefully, because we don't

We supply no credentials and allow 45 seconds. That is a deliberate choice — the harness exists to find out what a server does with a hostile-by-default environment, not to make servers look good. It also means the failure column is substantially our doing.

A server that wants an API key we declined to give it has not failed. A server that needs three minutes to install a browser engine has not failed. We separate these because collapsing them into "broken" would be a false claim about someone else's project, published at scale, with our name on it:

• needs credentials — refused for want of auth we intentionally withheld
• failed to start — didn't come up, and not obviously an auth problem
• unsupported — we can't run it: no install command, or it targets another OS

That last category exists because the first run turned one up immediately: a macOS-only package on our Linux runner. That is our limitation, not a defect, and calling it one would have been wrong.

So 36% is a floor on how many of these servers work, not a measurement of how many don't. If you want a headline number, that is the only honest one available.

The finding we didn't go looking for

The servers that do start take a long time to become usable:

Thirteen seconds is the median. Add four servers to your client config and you are waiting the better part of a minute before the agent can do anything, every session, because npx re-resolves the package each time.

Nobody publishes this because measuring it requires actually starting the servers. It is the strongest practical argument we have found for connecting on demand rather than pre-loading everything, and we found it by accident while measuring something else.

We scanned the tool descriptions. They're clean.

Connecting to servers produces a corpus nobody else has: 2,626 tool definitions from 85 servers, 2,617 of them carrying a description, and every one carrying an input schema.

That corpus is also an attack surface. Tool poisoning — CVE-2025-54136, "MCPoison" (secondary source) — hides instructions inside a tool's description, which MCP hands to the model unsanitised. A description is documentation; text telling the assistant to ignore prior instructions, or to conceal what it did, is something else.

We scan every description against the published patterns on every verification, and re-ran the same scanner across the whole stored corpus of 2,617 descriptions for this post.

Five matches across four servers. All five benign on inspection:

• two documentation servers saying "You MUST use this tool if you're unsure about…" — pushy, and honest about it
• an SSH server naming the ~/.ssh paths it exists to read
• two tools on a hosting provider that manage .env variables, and say so

Zero injections. That is the headline, and we would rather publish it than sit on it waiting for something more dramatic. A scanner that has never fired is worth nothing; one that fires at a rate a human can review, and whose hits all turn out legitimate, is calibrated.

These are flags for review, never verdicts. A regular expression cannot tell a usage hint from an injection, and we do not publish flags against named servers as accusations.

Are any of these commercial?

Of the 85 verified servers, 14 have tools whose descriptions reference pricing, quotas, free tiers or upgrades — but on inspection that means the service behind the server is commercial (Microsoft 365, Bitwarden, Figma), not that the server is a paid product.

We initially wrote that we had found no example of an MCP server that is itself sold. That was wrong, and the way it was wrong is more interesting than the claim.

Devart — a long-established database tooling vendor — sells a line of 20 MCP servers, licensed perpetually or by subscription, with a trial. They are a commercial product in the ordinary sense.

Our index contains none of them. Searching it for "devart" or "dbforge" returns nothing, because they ship as licensed downloads rather than as npm or PyPI packages, and our crawler only sees public package registries and GitHub.

So there is a whole category of MCP server that is invisible to us, and to every other count built the same way — which is to say, all of them. The previous post argued that every published figure depends on an unstated definition. This is a sharper version of the same problem: commercially distributed servers don't appear in anyone's numbers, including ours, and we only noticed because a vendor's release note happened to cross our desk.

We still have no idea how large that category is. Neither, as far as we can tell, does anyone else.

What we don't claim

• Not that 46% of MCP servers are broken. We withheld credentials and allowed 45 seconds. Most of that column is our harness.
• Not that this sample represents the ecosystem. 182 attempts against ~41,900 runnable entries, ordered by downloads, so it is biased toward popular npm packages.
• Not that our index is complete. It is built from public package registries and GitHub, so commercially distributed servers — sold as licensed downloads — are absent entirely. We found one such vendor by accident and have no way to estimate how many more exist.
• Not that the scan proves safety. It matches published patterns in descriptions. It cannot see what a server does at runtime, and it does not inspect tool responses — the runtime-injection channel remains the significant unsolved problem, industry-wide.
• Not that startup latency is anyone's fault. Much of it is npx resolving packages, which is a packaging characteristic, not a server defect.
• We are not neutral. We run a registry and a gateway. The method is described so it can be argued with; the numbers come from a public API.

Reproduce it

Every verification is a row, and the result is on the public API:

curl -s "https://mcprating.io/api/v1/servers/notionhq-notion-mcp-server" | jq .verification

{ "lastVerifiedAt": "...", "verifiedCount": 1, "attemptCount": 1, "latestOutcome": "verified" }

null means we have never attempted that server — not that it is broken. At the time of writing that is true of the overwhelming majority of the index, and it will stay true for a long time.

The pass runs weekly and the history is append-only, so the interesting number isn't today's snapshot — it's which servers stop working, and when.