Census
How many MCP servers are there?
The short answer is 8,753 in this index, drawn from every public registry and from manifests on publishers' own domains. The useful answer is smaller: of 8,593 endpoints we could actually try, 2,652 answered a standard handshake and returned a tool list. Counting listings and counting servers are different measurements, and only one of them tells an agent anything.
Why the number is always different
Ask three directories how many MCP servers exist and you get three answers, none of them wrong. They are counting different things. One counts submissions to a registry. One counts GitHub repositories with a matching topic. One counts entries it has aggregated from the others, including duplicates under different names.
None of those is a count of servers. They are counts of claims, and a claim is a line somebody typed into a form. The gap between a claim and a server is the whole subject of this post.
The census
This index aggregates the official MCP Registry, every public ARD registry, an OpenAPI corpus, GitHub, Hugging Face, and manifests served on publishers' own domains. Deduplicated by endpoint and identifier, as of 5 September 2026:
| Resource family | Entries |
|---|---|
| MCP servers | 8,753 |
| Skills | 2,810 |
| OpenAPI services | 2,670 |
| Documentation resources | 279 |
| A2A agents | 80 |
| Registries and catalogs | 28 |
| Total entries | 14,821 |
Two things in that table are worth pausing on. MCP servers are 59 percent of everything, which matches the attention the protocol gets. And A2A agents are 80. The agent-to-agent layer is talked about as though it were comparable to the tool layer, and by published-resource count it is roughly one percent of it.
Then we called them
A count of listings tells an agent nothing, because an agent does not consume listings, it connects. So we connected: two read-only JSON-RPC calls per endpoint, initialize and then tools/list, over streamable HTTP, with a short timeout and no retries. No tool was ever called.
8,593 endpoints were reachable enough to attempt. Here is what happened.
| Outcome | Endpoints | Share |
|---|---|---|
| Answered with a tool list | 2,652 | 30.9% |
| Answered, credentials required | 2,094 | 24.4% |
| Failed outright | 3,847 | 44.8% |
Fewer than a third of listed MCP servers will complete a handshake with a stranger and tell them what they can do.
The middle row is the one most often misread. Credentials required is not a failure. Those 2,094 endpoints are real servers behaving correctly: they answered, and they want authentication before exposing a tool list. What is notable is that almost no directory records this, so an agent discovers it by trying and failing, and a developer discovers it by reading a stack trace.
What the failures actually were
| Failure | Endpoints | Usually means |
|---|---|---|
| 404 | 1,237 | The listing is stale. Nothing is served at the address the entry gives. |
| 422 | 1,160 | Something answers, but it does not speak the protocol. |
| 405 | 563 | Wrong method at that path, often an SSE-era URL. |
| connection error | 319 | The host is gone. |
| 429 | 211 | Rate limited before it would talk to us. |
| handshake | 128 | TLS failed. |
| 402 | 69 | Payment required. |
1,237 endpoints answer 404 at the address their own listing gives. That is the single largest failure mode, and it is not a protocol problem. It is a bookkeeping problem: something moved and no directory noticed, because most directories never check.
What survives
The servers that did answer returned 97,472 verified tools between them, each one with the name, description and JSON input schema its own server reported. That is the part worth having. A tool description copied from a README is marketing. A tool description returned by tools/list is what the agent will actually be handed.
It also produces a finding that is easy to miss in aggregate: 122 different publishers ship a tool called search. 62 ship one called fetch. Names alone cannot disambiguate an ecosystem at this size, which is a discovery problem rather than a naming problem.
How to read any MCP server count, including this one
- Ask what was counted. Submissions, repositories, or endpoints that answered. The three differ by a factor of three.
- Ask when. A count with no date is a number from an unknown moment. 1,237 dead endpoints in this index were live at some point.
- Ask whether anyone connected. Most counts are of text, not of servers.
- Treat auth-required as working. A directory that reports it as broken is measuring its own lack of credentials.
Our own count fails the second test the moment you read this page in a month, which is why the date is in the standfirst and the underlying figures are served as JSON.
Method
Entries deduplicated by endpoint URL and by urn:air identifier. Introspection is two read-only calls with a short timeout, no retries, and a project user agent. Endpoints answering 401 or 403 are recorded as auth-required rather than failed. Counts are as of 5 September 2026 and move daily. No tool was invoked at any point, and nothing here required credentials from anyone.
Use Neuronto from your agent
One call searches this index and every other public ARD registry. No key, no signup. Or install it as an MCP server and let the agent search from the interface it already speaks.
curl -s https://neuronto.com/search \
-H 'content-type: application/json' \
-d '{"query":{"text":"scrape a website"},"federation":"auto"}'
claude mcp add --transport http neuronto https://neuronto.com/mcp