Can Your Agent Search for MCPs?
How one line of configuration lets your agent find the right tool mid-task.From source of truth to the search bar your agent calls.Can my agent search for the right MCP itself? Sooner or later, every agent builder asks.Short answer: not against the official registry directly. Long answer: yes - and…
How one line of configuration lets your agent find the right tool mid-task.From source of truth to the search bar your agent calls.Can my agent search for the right MCP itself? Sooner or later, every agent builder asks.Short answer: not against the official registry directly. Long answer: yes - and it takes one line of config. This post is the bridge between the two: by the end, your agent runs the search, not you.The official registry is a warehouse other programs crawl; your agent needs a search bar, and that is a different thing.Why the official registry has no search for your agentThe official registry lives at registry.modelcontextprotocol.io, and it is the source of truth for MCP (Model Context Protocol) servers. But it is a machine-readable list built for other software to bulk-download and re-list, not a search service your agent can talk to. It is deliberately unopinionated. It is not itself an MCP server.So your agent cannot call it the way it calls any other tool - there is no mcp_search to invoke, no endpoint to point a client at. And there is no first-party discovery server anywhere, not on the registry and not as a steering-group reference. This is a stated design choice: tool discovery is somebody else's job, not an oversight.The people building on the protocol feel it. Discovery keeps coming up as the friction point in the protocol’s own GitHub discussions. There is still no settled answer - no agreed-on contract for how an agent probes and finds servers on its own.Your agent can browse the web only if something hands it a door. The registry does not. So I built the door.The registry is built for other programs to crawl, not for your agent to call.A directory that crawls, grades, and prunesThe bridge is a directory. It crawls the official registry, grades every server with an LLM, and drops the dead ones. What reaches your agent is 17,000+ working servers, not a raw dump.That pruning matters. A 2026 audit of about 1,850 publicly listed servers - across GitHub, npm, PyPI, and four community registries - found 52% of them abandoned. The registry’s raw feed, unopinionated by design, has no way to filter that before an agent sees it.The hard problem was never finding a server. It was knowing which servers are real and maintained. The directory’s categories are LLM-graded, not rule-based trust scores, so grading is what weeds the graveyard out.Your agent sees working servers, not dead links.A directory earns its keep by what it removes - the dead servers your agent should never see.The tool your agent callsNow the payoff. The directory exposes three tools. mcp_search finds servers by task. mcp_get returns one server's packages and its install command. mcp_categories lists the filters. The tool descriptions are the router: the model reads them and picks. Three tools, not forty - a search bar, not the context bloat people fear from large tool sets. One receipt:One call from your agent: 73 ranked servers, best match first.From source of truth to the search bar your agent calls.One call from your agent: 73 ranked servers, best match first.Ranking matters because results are rarely unique: a common database name returns a dozen near-identical servers, and ranking picks the maintained one instead of an hour of hand-comparison.There are two ways to point a client at it: the remote endpoint https://catalog.agentage.io/mcp (Streamable HTTP, no auth, no install), or a local one-liner, npx -y @agentage/find-mcp. On Windows, if npx is flaky, use the remote URL instead.So why ship an npm package when the URL already works? Because it makes connecting simple. Wiring an unlisted remote server by hand means editing JSON, and the exact key differs from client to client. The npx command block is the one shape nearly every client accepts the same way. One line replaces a per-client config puzzle.{ "mcpServers": { "find-mcp": { "command": "npx", "args": ["-y", "@agentage/find-mcp"] } } }One line for Claude Desktop, Cursor, and Windsurf; VS Code takes the same block under a servers key.That is the friction the one-liner removes. The old way meant browsing registries by hand, working out each server’s transport type and env vars, and editing mcp.json yourself. Thirty seconds of setup, and your agent searches 17,000+ servers.Your agent finds the right tool mid-task. You never open a config file to find it.Your agent should find the right tool mid-task, not wait for you to hand-edit a config file.Registry to directory to the one tool your agent calls.The client is almost nothingHere is the part I like. The published client is 290 lines of code. No search logic, no ranking, no categories. It only connects to the directory, forwards the call, and reconnects if the link drops.All the intelligence lives server-side in the directory. The client is read-only by design: it never installs or runs anything it finds. That is why no auth is fine - it reads a public directory and changes nothing. When a team needs a governed, audited path to a server, that is a different tool - find-mcp finds servers; it does not gate access.That thinness is deliberate. The directory is the product.The directory is the product; the client is 290 lines on purpose.A crowded field with no leaderI am not first here. “An MCP that searches for MCPs” is a crowded, shallow corner of developer tools - around ten projects, almost all single-maintainer and thinly maintained.MCP Compass: 245 stars, but dormant, with no commits since January 2025.MCPfinder: the closest analog on the axis that matters, since it also pulls the official registry.Smithery: a hosted registry and CLI, more a marketplace than a discovery tool your agent calls.No first-party discovery MCP from Anthropic or the protocol steering group.The bigger players sit one tier up: AWS AgentCore, Google, and Kong now expose their own registry over MCP, but those doors are cloud-locked and gated. find-mcp’s moat is the opposite - public, no auth, no install, self-published into the official registry.So the difference is not the tool shape. Three tools is becoming the convention. The difference is the directory: fed by the official registry, and published back into it as a first-class entry,io.agentage/find-mcp, with LLM-graded categories. Because it is itself a registry entry, the MCP that finds MCPs can find itself.The official registry’s own curated, verified directory is roadmapped for Q4 2026 and has not shipped, so for the public, no-auth lane the seat is still open.The seat for a canonical discovery server is still open, and it is won on directory quality, not tool shape.You used to browse; now you ask.That is the whole change. You used to browse and hand-edit config. Now your agent asks - and because the directory lists itself back as io.agentage/find-mcp, your agent can even find the tool that finds its tools.The code and the package are public: github.com/agentage/find-mcp and @agentage/find-mcp, published July 2026.About the authorVolodymyr Vreshch builds catalog.agentage.io, the MCP directory behind @agentage/find-mcp, and writes about agents, MCP, and developer tooling at vreshch.com. Senior Software Engineer. On GitHub: Volodymyr VreshchThis story is published on Generative AI. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories.Subscribe to our newsletter and YouTube channel to stay updated with the latest news and updates on generative AI. Let’s shape the future of AI together!Can Your Agent Search for MCPs? was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.Source: Generative AI Pub — Published — Category: Image AI