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

A developer built mcp-anything, a meta-server that indexes and searches over 75,000 MCP servers, providing five meta-tools for discovery and execution while keeping context costs constant. The project uses BM25 lexical search with popularity boosts instead of embeddings, pools live client sessions, and prioritizes security with SSRF guards and no arbitrary code execution by default. The developer argues that the current MCP workflow is broken because users must know which server to configure in advance and each added server consumes context tokens.

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. 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. mcp-anything https://github.com/Dror-Bengal/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 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. 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 https://dev.to/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. 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 https://github.com/Dror-Bengal/mcp-anything · Try discovery now: https://mcp-anything.onrender.com https://mcp-anything.onrender.com · 49 tests, CI green, no telemetry, no cloud account. Disclosure: built in the open with heavy AI pair-programming — every design decision reviewed, every line tested.