As AI agents and MCP servers multiply, keeping track of what is actually available stops being something a person can do by hand. Agentic Resource Discovery, or ARD, is a shared specification aimed at exactly that problem. It is published under the Apache License 2.0, and engineers from 11 companies including Google, Microsoft, GitHub and NVIDIA took part in its design and review. Amazon Web Services contributed feedback during development and, on August 24, laid out how the spec fits alongside its own AWS Agent Registry[1].
The shortage is not tools, it is an index of tools
What an AI client can call today goes well beyond what the model remembers. Tools, Skills, MCP servers, APIs, workflows, other agents. The ARD documentation groups all of these under the term agentic resources.
The trouble is that they are appearing faster than manual effort can absorb. Someone has to find a resource, judge whether it is useful and trustworthy, wire it into the client, and keep that wiring current. That holds up when a handful of well-known tools exist. It stops holding up once internal teams, vendors and individuals are all publishing their own. Worse, configuring something for one client does not make it usable from another.
So the bottleneck is not invocation. It sits one step earlier, at discovery. A client cannot use a capability it does not know exists, and no company can expect every employee to memorize which internal tools and approved services apply to which task.
ARD only defines the entrance to search
ARD's scope is drawn surprisingly narrowly. The client asks a single question: what agentic resource can help with this task? What comes back is a set of matches describing what each one does, who provides it, where it lives, and how to reach it.
Everything after that is out of scope. Invocation happens through the selected resource's own mechanism, whether that is MCP, an API or an agent framework. It helps to picture ARD as a layer that sits just before invocation.
The search interface is defined by three endpoints.
| Endpoint | Purpose | Status |
|---|---|---|
| POST /search | Find resources by task | Required |
| POST /explore | Browse and filter the collection | Optional |
| GET /agents | List the collection's entries | Optional |
Describing the resources themselves is handled by the ARD entry. In v0.91 of the spec an entry is a JSON-LD node, which gives very different kinds of resources one consistent way to state what they do, who provides them, where they live and how a client reaches them[2]. Publishers put their entries at /.well-known/ard.json on their own domain. The predecessor path /.well-known/ai-catalog.json is now treated as an optional legacy name, and the current spec tells publishers to move to ard.json[2].
ARD does not dictate what goes into a collection, how it is ranked, where it is hosted or how it is monetized. A collection can be wide open, covering anything published on the web, or tightly curated down to an approved set. The spec itself expects most enterprises to want the curated case.
Who implements it, and who connects to it
A collection exposed through this interface is what the spec calls an Agent Registry, though implementations usually surface under the agent finder label. GitHub's Agent Finder, Hugging Face's Discover Tool, Cisco's AI Catalog, the Ora Directory and the self-hostable ANS Finder are all listed as reference implementations[3].
On the consuming side, clients such as Claude, ChatGPT, GitHub Copilot, Microsoft Copilot and Gemini reach an Agent Finder through a Skill or a remote MCP connector. Ask it to find a capability for a task, review the matches, and decide what to install.
AWS approaches the same problem from the internal catalog side
The piece AWS is pushing at the same time is AWS Agent Registry, an in-house catalog built from two layers: registries and registry records.
The workflow runs in four stages. An administrator creates a registry and configures approval settings plus authorization through IAM or a JWT from the corporate identity provider. A publisher describes their MCP servers, agents or tools as records and submits them. A curator reviews, approves or rejects, and deprecates records that fall out of use. Consumers, human or agent, then search for what they need.
Search is hybrid, combining semantic understanding with keyword matching, so natural-language queries and exact name lookups both work. The registry is itself available at a remote MCP endpoint, so any MCP-compatible client can query it directly. With cross-account sharing, one registry can serve an entire AWS Organization.
The analogy reached for is DNS
A registry confined to one environment still cannot answer cross-environment questions. When multiple clouds, on-premises systems, SaaS platforms and business applications each keep their own catalog with its own format and naming convention, every pair that needs to interoperate demands a bespoke connector.
That gap is where AWS expects ARD to land. In its framing, ARD brings to registry federation the same relationship DNS has to name resolution across networks. If each environment's catalog exposes an endpoint speaking a common protocol, cross-environment search works without stacking up bilateral agreements.
Federate without migrating, discover broadly while keeping control local, and publish a catalog on your own domain so outside organizations can find it. All three of the goals AWS lists assume existing access controls stay exactly where they are.
Summary
ARD is not a product. It is an open agreement that carves out the discovery piece alone. By limiting itself to the entrance to search, it can sit on top of existing MCP and API plumbing without conflict. The moment 11 company names lined up behind it, the assumption that agent counts will keep climbing became shared ground. What remains to be seen is how many organizations actually publish their catalogs in this format. This is the kind of standard decided less by the elegance of the spec than by the volume of what ends up listed in it.
出典:https://agenticresourcediscovery.org/spec/
出典:https://agenticresourcediscovery.org/ref_implementations/
