MCP has a discovery problem. I built a meta-server that searches all 75,000 servers.

dror bengal — Fri, 21 Aug 2026 20:40:29 +0000

There are now tens of thousands of MCP servers. Glama indexes ~75,000. PulseMCP lists ~22,000. npm has thousands of packages tagged mcp-server. And yet the way we all use MCP is: find a server somewhere, paste it into a config file, restart the client, repeat.
Two things are broken about this.

Discovery is manual

Your agent can't answer "is there a tool that queries Postgres?" — you have to know the answer, find the server, and wire it up before the conversation even starts.
Every server you add costs context, forever. Each configured server loads its tool schemas into every request. Ten servers with a dozen tools each, and you've burned thousands of tokens before saying hello. This is why most people cap out at a handful of servers — not because they don't want more capabilities, but because context is expensive.

Inverting the model

mcp-anything is a single MCP server that inverts this. Instead of you configuring N servers, the model gets exactly five meta-tools:

search_mcp_servers → BM25 search over the indexed ecosystem
describe_mcp_server → transports, env vars, security verdict
list_mcp_tools → live connect, real schemas for ONE server
call_mcp_tool → execute (sessions pooled and reused)
sync_registry → refresh the index

The index is built by syncing four catalogs — the official MCP registry, PulseMCP, npm search, and Glama — deduplicating across them by normalized repository URL and package identity, and merging popularity signals (GitHub stars, npm downloads). Ask for a capability, get the best server for it, pull its real schemas, execute. Context cost stays constant no matter how big the ecosystem grows.

claude mcp add anything -- npx -y mcp-anything serve

Design decisions worth arguing about

Lexical search, not embeddings. Everyone's first instinct (mine included) is a vector database. I went with BM25 (MiniSearch) plus a log-scaled popularity boost instead: fully local, zero API cost, no index build step — and for tool discovery it performs comparably. Anthropic made the same call for Claude's native Tool Search. With 75k servers, the real ranking problem isn't semantic nuance; it's keeping the hundredth abandoned "gdrive-upload" clone out of the top 5. Stars and download counts solve that better than cosine similarity does.
Sessions, not stateless proxying. MCP is not stateless RPC — there's an initialize handshake and capability negotiation. Treating downstream calls as one-shot requests breaks real servers. mcp-anything pools live client sessions with LRU eviction, so repeated calls to the same server reuse the connection.

Security is the actual product. Pointing an LLM at a public catalog of arbitrary servers is a genuinely scary idea, and I think any aggregator that doesn't lead with this is being irresponsible. The defaults:

SSRF guard: a registry entry whose endpoint points at loopback, private ranges, or a cloud metadata address (169.254.169.254 — yes, there's a test fixture with a fake "metadata-stealer" server) is refused.
No arbitrary code execution: spawning stdio servers via npx/uvx is off by default, and enabling it requires an explicit per-package allowlist, version-pinned.
Secrets never indexed: API keys live only in your local config, injected at connect time, never cached or shown to the model.
Untrusted output, labeled: tool descriptions and results from downstream servers are marked as third-party data. This mitigates tool-poisoning; it does not solve it. Nobody has solved it. The SECURITY.md says so out loud.

Public hosting must be neutered. There's a hosted instance at mcp-anything.onrender.com you can point any MCP client at to try discovery right now — but it runs in a discovery-only mode that exposes just search/describe. A public instance with call_mcp_tool enabled would be an open proxy that executes anything against anyone. The Dockerfile defaults to discovery-only for exactly this reason.

What I learned shipping it

The unglamorous parts were the real work. npm rate-limits fast pagination (429s) — the sync needed retry-with-backoff and politeness delays before a full index run survived. The official registry rejects descriptions over 100 chars and enforces case-sensitive namespace ownership down to the mcpName field inside the published npm package. Cross-source dedupe sounds trivial until the same server appears as io.github.acme/weather, pulse/weather-mcp, and npm/@acme/weather-mcp with three different metadata shapes.
And the honest positioning question everyone should ask: gateways like MetaMCP aggregate servers you already configured; Composio's Rube routes to its own hosted catalog; native tool search in clients searches tools already connected. The open combination — public registries as the catalog, local-first single binary, explicit security policy, works against a private registry — was the gap. Whether it stays a gap is a fair question; it's MIT-licensed either way.

What's next

Per-tool indexing (search actual tool names/schemas of popular servers, not just server descriptions), live health signals in ranking, and container sandboxing for stdio as an alternative to allowlisting. The repo has good-first-issues if any of that sounds fun.

Repo: https://github.com/Dror-Bengal/mcp-anything ·
Try discovery now: https://mcp-anything.onrender.com · 49 tests, CI green, no telemetry, no cloud account.