Our Take
ARD solves a real scaling problem (agents can't discover thousands of tools dynamically), but it's a plumbing spec, not a product shift—the architecture change matters more than the announcement.
Why it matters
Today, agent developers hardcode tool URLs into config files or dump all tool descriptions into the LLM's context window, both of which fail at scale. ARD moves discovery outside the model and outside manual configuration, letting agents find capabilities at runtime across federated registries.
Do this week
Agent builders: test the Hugging Face Discover Tool this week by running 'hf discover search "your use case"' so you understand how runtime discovery will change your capability-loading logic.
Hugging Face publishes ARD reference implementation
Hugging Face has published a working reference implementation of Agentic Resource Discovery (ARD), a draft open specification co-authored by contributors from Microsoft, Google, GoDaddy, Hugging Face, and others. ARD defines how agents discover tools, skills, and other agents at runtime instead of requiring pre-installation.
The specification has two core components. First, a static manifest format called ai-catalog.json that publishers host at a well-known URL. Second, a dynamic registry API with a POST /search endpoint that returns ranked results in natural language.
Hugging Face's Discover Tool wraps the Hub's existing semantic search into the ARD envelope, surfacing thousands of Spaces, Skills, and MCP servers through a single interface. The CLI command hf discover search "fine tune a language model" returns results filtered by type (skill, MCP server, or raw Space metadata). A REST API endpoint and MCP protocol connection are also available for programmatic access.
The implementation handles media-type negotiation automatically. A Spaces tagged as MCP servers return MCP catalog entries; others return Skill manifests wrapping the Space's agents.md metadata. The adapter filters results to include only running Spaces and applies the requested content type on the fly.
The scaling problem is real; the solution shifts discovery logic
The current model is install-first, use-later. A developer hardcodes tool URLs into a config file; a user manually connects services via plugins. This works for a handful of daily tools but breaks under load.
The fallback—dumping all available tool descriptions into the LLM's context window—wastes tokens and often returns wrong choices because descriptions are too thin to disambiguate.
ARD moves selection outside the model and outside manual config. Agents query a registry with richer signals: publisher identity, compliance attestations, tags, and representative queries. The client receives ranked results and invokes the best match without pre-configuration. This is fundamentally different from the current model, not an incremental addition to it.
The federated design is the second-order win. Because the protocol is plain HTTP REST and the manifest format is media-type driven, any service can implement ARD independently, and searches can surface capabilities hosted elsewhere. One agent calling one registry can discover tools published through another registry entirely.
Audit your tool-loading architecture now
If you build agents today, you are either hardcoding tool URLs or dumping descriptions into context. Neither scales. Spend this week understanding how ARD changes the model: agents no longer need to know about tools at startup; they search at runtime and invoke dynamically.
The Hugging Face Discover Tool is available now. Run the CLI to see what discovery looks like. If you publish Spaces or MCP servers, ensure they carry agents.md metadata or mcp-server tags so they surface in search results. If you build agent infrastructure, prepare to support registry queries instead of static tool manifests—the protocol is stable enough to build against today.