Agentic Resource Discovery (ARD) is an open, federated specification that puts a discovery layer in front of agents: instead of preinstalling tools, the agent can search for capabilities at runtime. The proposal has broad industry participation (Microsoft, Google, GoDaddy, Hugging Face and more) and is intended as a standard, not a centralized product.
What problem does ARD solve?
Today many agents still follow an "install first, use later" model: the developer pins URLs, the user connects plugins, and the list of tools grows manually. What happens when the ecosystem reaches thousands of ad-hoc surfaces? It doesn’t scale.
Dumping every description into the LLM context window isn’t the answer either: the window has a limited budget and descriptions are often too thin to disambiguate capabilities. ARD moves selection outside the LLM: a registry indexes tools with rich signals (publisher identity, representative queries, compliance attestations, tags) and exposes a REST endpoint that accepts natural language searches. The agent queries that registry and executes what the search returns. It’s moving from static catalogs to intention-based search.
What does the specification define?
The ARD specification mainly defines two artifacts:
A static manifest format: ai-catalog.json. It lets publishers announce their capabilities at a well-known URL.
A dynamic registry API: POST /search. It provides live discovery and relevance-ranked results.
The idea is simple and powerful: clear contracts (manifest + REST API) that anyone can implement and federate.
Reference implementation: Hugging Face Discover Tool
Hugging Face launched "Discover" as a reference implementation. It turns the Hub and its Spaces into ARD catalog entries by combining the Hub’s semantic search with agent-oriented metadata.
Key points of the adaptation:
The Hub’s semantic search supports a flag agents=true that prioritizes Spaces with agent metadata.
The adapter filters to include only Spaces whose runtime stage is RUNNING.
The adapter supports three media types in the response:
application/ai-skill: default. Returns a generated SKILL.md-style version that wraps the Space’s agents.md with frontmatter (name, description, origin).
application/mcp-server+json: catalog entry for MCP servers, when the Space is labeled mcp-server.
application/vnd.huggingface.space+json: raw Space metadata for clients that want to manage it directly.
When a Space includes agents.md, Discover transforms it into a standard skill with fields like name, description, and origin metadata (Space ID, URLs). For Spaces labeled as MCP, the catalog points to the Space’s Gradio MCP endpoint (using the runtime domain if available or the .hf.space slug).
Practical examples: CLI and API
Discover is integrated into the Hugging Face CLI. Some commands to try:
Install the tool (if you need it):
uv tool install huggingface_hub
Search for resources to fine-tune a model:
hf discover search "Fine tune a language model"
Find MCP Servers to generate an image:
hf discover search "Generate an image" --json --kind mcp
Also, any MCP client can point to Discover’s MCP endpoint at https://huggingface-hf-discover.hf.space/mcp.
Architecture and federation modes
ARD separates discovery and execution. The manifest is driven by media types, which lets different artifact protocols share the same "envelope" without changes to the spec. The registry API is HTTP REST, so any client can federate.
The specification includes federation modes (for example auto, referrals, none) that define how searches flow between registries. Discover is already a functional proof: it doesn’t invent a new artifact format, it wraps the Hub’s search backend in the ARD envelope and exposes Spaces as skills or MCP servers depending on the client’s request.
Planned technical next steps: tighter support for federation modes and allowing user and organization profiles to publish ai-catalog.json on the Hub via a well-known URL.
What this means for developers and companies
For agent developers: you no longer need to preconfigure every tool. You can search for capabilities by intent and load what’s needed at runtime.
For publishers: exposing an ai-catalog.json and an agents.md increases the visibility of your skills and MCP servers in a federated ecosystem.
For platforms: adopting ARD makes it easier for heterogeneous clients to discover and consume capabilities without integrating every proprietary protocol.
Risks and considerations: discovery quality depends on metadata, trust attestations, and governance practices. Publisher identity, signatures, and compliance attestations will be critical for sensitive use cases.
Conclusion
ARD is a step toward more flexible agents: it swaps the question "do I have this installed?" for "which tool satisfies this intention right now?" If you work with agents, it’s worth experimenting with ai-catalog.json, exposing agents.md in your Spaces, and trying the Discover Tool to see how it fits your workflow.