Agent Finder¶
Discovery for the age of agents: an augment that no one knows of is of no use.
LLMs increasingly rely on external capability augments like MCP tools, Skills, or the ability to invoke other agents.
Unfortunately, an augment that no user knows of is of no use. This is the discovery problem, which gets worse as more augments are created. The end user or even IT admin cannot be expected to track everything that is created, judge what is trustworthy, and assemble the right set for each task, and keep doing it as the catalog grows.
We have seen this before. In 1994, finding something on the web meant a bookmark you had stumbled onto and saved yourself, or a hand-maintained list someone else kept. That is roughly where MCP tools and Skills sit today: useful, but reachable only if you already found them and added them. The web didn't stay there. Search engines took discovery off the user and put it in a service you ask, and that is what unlocked the scale. Agent Finder is that step for augments.
The next step¶
The discovery problem is well recognized, and the work so far has come in two kinds. Toolbox (Microsoft Foundry) and MCP registries provide mechanisms to create curated sets of augments — a vetted collection a developer can point at. ToolLLM (Qin et al., 2023) and Claude's tool-search take a different step: they make selection cheaper by moving part of it out of the context window, retrieving the relevant augments per query rather than injecting all of them.
Agent Finder takes the next logical step: an abstraction layer over both. It is a protocol, not a product or a particular search engine, and it pins down two things while leaving the rest open: how an augment is described, and how a client asks the discovery question and reads the answer. The service that answers can be built however its provider chooses — including with the very techniques above. This turns the existing curated sets into something a client calls uniformly, so an augment published once is found by many clients, and a client reaches augments far beyond its own pre-connected set.
Find, don't invoke
Agent Finder finds, it does not invoke. Discovery returns which augment fits and where to reach it; invocation happens over that augment's own protocol.
Many composable instances¶
Because Agent Finder is a protocol rather than a single service, we expect many instances, each defined by what it indexes and how it ranks. On the public web, some will compete on curation — a smaller, vetted index with a high bar for quality and trust — and others on coverage, indexing everything they can find to maximize recall. A client gets different answers depending on which it asks, the same way different search engines return different results.
The more consequential case is the enterprise. An IT or platform team runs its own instance and decides entirely what goes in it: internal augments, augments from vendors the company holds paid subscriptions to, approved third parties — and nothing else. Because the client discovers only through that instance, the team has total control over what augments employees can find and therefore use. This is the inverse of the open-web model, and deliberately so: discovery becomes the enforcement point for procurement, security, and compliance, without the team having to integrate each augment into each client by hand. Whoever runs the instance controls the answer set.
Because the protocol allows aggregation across endpoints, control also means composition. An IT manager can define their instance as "everything GitHub's Agent Finder serves, plus the augments in our internal one" — a union of a public endpoint and a private one, queried as a single view.
The DNS property
This is a property DNS has and web search does not: DNS resolvers compose, forwarding to upstream servers and merging the global namespace with local zones, so every organization runs its own resolver without leaving the shared system. Web search has no equivalent — you query one engine's index, and there is no standard way to say "these results plus my company's, merged." Agent Finder inherits the DNS property: instances compose, so an enterprise extends the public ecosystem rather than walling itself off from it.
Using Agent Finder¶
Agent Finder is exposed to a client as a Skill, and equivalently as an MCP tool. In GitHub Copilot, Claude, ChatGPT, and other clients, the user adds the Skill or connects the MCP tool. Once in place, the client queries Agent Finder for what can handle a request rather than being limited to what was wired up in advance.
The other side is publishing. Anyone with an augment they want discovered — a single tool or skill, or a whole internal set — describes it in a standard catalog file, hosts it on their own domain, and advertises it via a well-known URL, a robots.txt entry, an HTML tag, or DNS. Any Agent Finder–compatible instance can then index those augments. The catalog is published once and reachable by every instance that chooses to include it, rather than integrated separately into each client.
Two distinct roles
Publishing a catalog makes an augment available to be indexed; running an instance decides what actually gets served to a given set of users.
The full specification and reference implementation are on GitHub.