We tested 37,000 MCP servers. Here's how many actually work

The official MCP registry now lists more than 62,000 servers. Most "best MCP servers" lists are written by hand from a few dozen of them. We wanted the whole picture, so we built a directory that connects to every remote MCP server in the registry the way an MCP client does, every day, and records what happens.

This is what we found in the first full run.

The short version

The full list, tested live every day, is at nestdaddy.com/mcp/servers.

How we tested

For every server with a remote endpoint we did what Claude, Cursor or VS Code does when you add a server:

1. Send initialize over Streamable HTTP (or open the stream for the older SSE transport).
2. Send notifications/initialized, then tools/list.
3. Record whether it answered, how long initialize took and which tools it exposed.

We never send credentials. A server that answers with HTTP 401 or 403 counts as live, key required: it is up, it just will not talk to strangers. HTTP 429 (rate limited) also counts as live. Each request has a 10 second timeout, and every check runs from a single server in Europe, so response times include the trip across the internet.

Finding 1: nine in ten servers answer

89.6% of remote servers answered. That is better than we expected for a registry where anyone can publish. The servers that did not answer failed in these ways:

A 404 or 405 usually means the registry entry points at the wrong path, for example the site root instead of /mcp. If you maintain a server, it is worth checking the URL you published.

Finding 2: one in three wants a key before it says anything

12,447 servers answered initialize with 401 or 403. That is a valid choice, but it has a cost: nobody can see what the server does until they sign up. Directories cannot list its tools, and an agent cannot decide whether it is useful.

The friendlier pattern is to answer initialize and tools/list for everyone and ask for the key only on tools/call. Users see exactly what they get before they create an account, and the actual work stays behind the key.

Finding 3: most servers answer in about half a second

Measured from one server in Europe, the time to answer initialize:

Location matters a lot here: a server in the US will look slower from Europe than it feels to a user in the US. Treat these numbers as a rough guide, not a ranking. What they do show is that the protocol itself is not the bottleneck. A server that takes several seconds just to say hello is usually starting from cold or doing work it should do later.

Finding 4: tool counts vary from 1 to 80

Across the servers that showed their tools, we found 292,447 tools.

• The median server exposes 7 tools.
• 815 servers expose exactly one.
• 4,325 servers expose 20 or more.

Tool count matters more than it looks. Every tool's name and description is sent to the model in every conversation, whether the tool is used or not. Add five servers with 30 tools each and the model starts every chat with 150 tool descriptions in its context. That costs tokens, and it makes the model worse at picking the right tool. Fewer servers with clear, well-described tools beat many servers with long tool lists.

Finding 5: 12% of the registry is spam

The registry is open, and it shows. Before testing anything we hid entries that are clearly mass-published:

• One GitHub repository is behind 2,356 "servers." Two more repositories account for another 2,200.
• Some descriptions appear on more than 150 different entries, word for word.
• In total we hid 7,839 entries (12.6%): any repository behind more than 10 servers, any description reused more than 3 times, and entries with almost no description.

Bulk publishing is not always spam, though. One publisher runs 1,710 live servers from a single gateway, one per public API, and every one of them shares the same 12 base tools (remember, recall, forget, company_facts and so on) on top of its own. That is a legitimate design, but it shows how much of the registry comes from a handful of publishers, and why a raw entry count says little about how many distinct products there are.

The registry is also growing fast. 17,515 entries were published in October, and 16,819 in the first 13 days of November alone. Expect the spam share to grow unless registries add stronger checks.

What this means if you build agents

Before you add a server to Claude, Cursor or your own agent, check three things:

1. Does it answer initialize without a key? If it does, you can see its tools before you sign up.
2. Does it list real tools with clear descriptions? One tool called query tells the model nothing.
3. Is it maintained? Look at when it was last updated, and whether it answered recently.

Our MCP server directory shows all three for every server, with ready-to-copy setup for Claude Code, Claude Desktop, Cursor and VS Code.

What this means if you maintain a server

• Answer initialize and tools/list without a key, and require the key only for tools/call.
• Make sure the URL in your registry entry is the MCP endpoint, not your homepage.
• Keep the tool list short and describe every argument. Agents pick tools from the descriptions alone.

Every server page in the directory has a badge you can add to your README. It turns green while your server passes the daily check.

We will publish this again

The directory re-tests every server every day, so we will repeat this report regularly and show what changed: how many servers came and went, and whether the registry gets cleaner or noisier. If you want a specific number we did not cover, tell us at hello@nestdaddy.com.

Originally published on the NestDaddy blog. NestDaddy gives your AI today's internet: live web search and real-time breaking news from its own index. nestdaddy.com/mcp