MCP's ceiling is the token bill, not the catalog: 75,000 servers nobody can afford to configure
A new meta-server proposes replacing N configured MCP servers with five search-and-connect tools. The saving is real, but the cost moves to round trips, and to whoever ranks in the top five.
The Engineer · Build desk
What happened
- mcp-anything replaces per-server configuration with five meta-tools: search, describe, list tools via live connect, call, and sync the registry.
- Its index merges the official registry, PulseMCP, npm search and Glama, deduped by repository URL and package identity and ranked with stars and download counts.
- The public hosted instance runs discovery-only, with execution disabled, and the Dockerfile ships that way by default.
Why it matters
- What it limits constraint The ceiling on agent capability is the per-request budget rather than the catalog, so every added server is paid for out of every later turn, and capability has to be bought back from tokens.
- Who has to decide decision Inverting discovery moves the trust call from install time, where a human read the repo, to run time, where a model picks from a ranked list; the version-pinned allowlist is where that call gets...
- Who's exposed exposure Any aggregator that can both discover and execute is one deployment decision away from being an open proxy, which is why the shipped default withholds the executing tool from anyone hosting it.
- What doesn't add up contradiction Two catalogs of the same ecosystem disagree by tens of thousands of entries, which means the widely quoted server count measures registry records rather than distinct servers you could usefully call.
The arithmetic is the whole argument. Ten servers at a dozen tools each is 120 tool schemas sitting in every request [5]; the meta-tool approach keeps five resident [6], roughly a 24-fold cut in what the model carries before it has heard the question [19]. That is a real saving and also a transfer. The schemas for the server you actually need still get loaded, only later, and `list_mcp_tools` pays for them with a live connect to that one server [6]. A fixed tax on every request becomes a variable cost with round trips attached: search, describe, list, then call.
The second-order effect is in the ranking function. The index merges four catalogs and boosts results by GitHub stars and npm downloads [7], with BM25 over MiniSearch rather than embeddings, which the author argues performs comparably for tool discovery at zero API cost [8]. His stated ranking problem is keeping the hundredth abandoned `gdrive-upload` clone out of the top five [23]. Accept that, and notice what it means: if the agent only ever sees five results, popularity counts become the distribution channel for tool use. Position, not availability, decides which server gets called.
Then there is the question of what "75,000" counts. Glama's index is about 75,000; PulseMCP lists about 22,000 [1][2] - a gap of some 53,000 records between two catalogs of the same ecosystem [20]. The author's own dedupe notes explain part of it: one server can appear as `io.github.acme/weather`, `pulse/weather-mcp` and `npm/@acme/weather-mcp`, with three different metadata shapes [17]. The headline figure is a count of registry entries, not of distinct working servers, and the sync work needed retry-with-backoff to survive npm's rate limits at all [15].
The security defaults cut against the premise in a way worth stating plainly. Spawning stdio servers via npx or uvx is off by default, and turning it on requires an explicit per-package allowlist, version-pinned [11]. So the model can search 75,000 entries and read a server's transports and env vars [6], but it cannot run a locally spawned one until a human has pinned that package by hand. Discovery is inverted; installation is not. Remote entries get an SSRF guard that refuses loopback, private ranges and the cloud metadata address [10], and downstream descriptions and results arrive labeled as third-party data, which the author says mitigates tool poisoning without solving it, because nobody has [13].
What is actually on offer, then, is not access to the ecosystem. It is a ranking over the ecosystem plus a standing refusal to execute most of it. That is a more defensible product than it sounds, and it is a different one from the existing gateways, which aggregate the servers you had already configured [18]. The constraint it addresses is a budget, not a directory, and budgets do not care how many entries the catalogs claim.
What to watch
- Whether Claude's native Tool Search widens far enough that a third-party discovery meta-server becomes redundant.
- Whether anyone stands up a public instance with call_mcp_tool enabled, and what starts getting proxied through it.
- Whether the official registry's case-sensitive namespace ownership hardens into signing or verification, which is what would make version-pinned allowlists maintainable at scale.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence24
- Adoption8
- Hype gap+42
- Incentives82
- Confidence33
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Glama indexes approximately 75,000 MCP servers.
- [2]
PulseMCP lists approximately 22,000 MCP servers.
- [3]
npm carries thousands of packages tagged mcp-server.
- [4]
The prevailing MCP workflow is to find a server, paste it into a config file, restart the client, and repeat; an agent cannot itself answer whether a tool exists for a given task.
- [5]
Each configured MCP server loads its tool schemas into every request; ten servers with a dozen tools each burns thousands of tokens before the first message.
- [6]
mcp-anything exposes five meta-tools: search_mcp_servers (BM25 search over the index), describe_mcp_server (transports, env vars, security verdict), list_mcp_tools (live connect for real schemas from one server), call_mcp_tool (execute, with pooled sessions), and sync_registry.
- [7]
The index is built by syncing four catalogs - the official MCP registry, PulseMCP, npm search and Glama - deduplicating by normalized repository URL and package identity, and merging popularity signals including GitHub stars and npm downloads.
- [8]
The search uses BM25 via MiniSearch plus a log-scaled popularity boost rather than embeddings: fully local, zero API cost, no index build step, and the author says it performs comparably for tool discovery and that Anthropic made the same call for Claude's native Tool Search.
- [9]
MCP is not stateless RPC: there is an initialize handshake and capability negotiation, so one-shot downstream calls break real servers; mcp-anything pools live client sessions with LRU eviction so repeated calls reuse the connection.
- [10]
An SSRF guard refuses registry entries whose endpoint points at loopback, private ranges, or the cloud metadata address 169.254.169.254.
- [11]
Spawning stdio servers via npx or uvx is off by default; enabling it requires an explicit per-package allowlist, version-pinned.
- [12]
API keys remain only in the user's local config, are injected at connect time, and are never cached or shown to the model.
- [13]
Tool descriptions and results from downstream servers are labeled as third-party data, which the author says mitigates tool poisoning but does not solve it, and the project's SECURITY.md states nobody has solved it.
- [14]
A hosted instance at mcp-anything.onrender.com runs in discovery-only mode exposing just search and describe, and the Dockerfile defaults to discovery-only, because a public instance with call_mcp_tool enabled would be an open proxy that executes anything against anyone.
- [15]
npm rate-limits fast pagination with 429s, so the sync required retry-with-backoff and politeness delays before a full index run completed.
- [16]
The official MCP registry rejects descriptions over 100 characters and enforces case-sensitive namespace ownership down to the mcpName field inside the published npm package.
- [17]
The same server can appear as io.github.acme/weather, pulse/weather-mcp and npm/@acme/weather-mcp, with three different metadata shapes.
- [18]
The author notes that gateways such as MetaMCP aggregate servers the user has already configured.
- [19]
Ten servers with a dozen tools each is 120 tool schemas loaded per request, against five meta-tools, a factor of 24 fewer schemas resident.
- [20]
The two catalogs differ by roughly 53,000 entries for the same ecosystem.
- [21]
The author argues most people cap out at a handful of configured servers because context is expensive, not because they do not want more capabilities.
- [22]
The author claims context cost stays constant no matter how large the server ecosystem grows.
- [23]
The author says the real ranking problem at 75,000 entries is keeping the hundredth abandoned gdrive-upload clone out of the top five results, and that stars and download counts do this better than cosine similarity.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toMCP has a discovery problem. I built a meta-server that searches all 75,000 servers.
1 article · August 21, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.