Agentic Resource Discovery: Let agents search

For all the talk about agents calling tools, agents calling other agents, and agents consuming skill files, nobody had solved the boring problem underneath all of it: how does an agent actually find the right tool in the first place? MCP, Skills, and A2A all assume you already know what you're looking for. Someone still has to hardcode a server URL or install a plugin before any of that machinery kicks in.

Agentic Resource Discovery, or ARD, is an attempt to fix that gap. It's a draft open specification with contributors from Microsoft, Google, GoDaddy, and Hugging Face, among others, and it's deliberately not a product or a marketplace — it's a shared protocol anyone can implement. The idea is simple enough: instead of stuffing every possible tool description into an LLM's context window and hoping the model picks well, a registry indexes capabilities with richer metadata (publisher identity, sample queries, compliance info, tags) and exposes a search endpoint. An agent queries in plain language, gets back ranked, relevant results, and invokes whatever fits. Two building blocks make this work: a static manifest called ai-catalog.json that publishers host at a well-known URL, and a dynamic POST /search API for live discovery.

Hugging Face built its own reference implementation, called Discover, and it's a genuinely clever repurposing of infrastructure that already existed. The Hub has long had semantic search over Spaces — the Gradio apps, demos, and MCP servers people publish — with an agents=true flag that ranks results by agent-friendly metadata. Discover just wraps that search in ARD's envelope. It filters to Spaces that are actually running, then serves results in whichever format the client asks for: a generated SKILL.md pulled from a Space's agents.md file, an MCP server catalog entry for Spaces tagged mcp-server, or raw Space metadata if the client wants to handle things itself.

You can try it right now through the Hugging Face CLI — a single hf discover search command lets you ask for something like "generate an image" and get back matching MCP servers, or point the same command at a completely different registry's catalog URL. There's also a straightforward REST API and an MCP endpoint if you'd rather wire it into your own client. None of this invents a new artifact format; it's the existing Hub search wearing a standardized costume so other ARD-compliant clients can understand it.

What makes the spec interesting isn't the manifest format itself, it's the federation built into the API. A search hitting one registry can, in principle, surface results hosted by a completely different one. Hugging Face says tighter federation support and manifest hosting for individual user and organization profiles are next, which would let any Space publisher advertise itself through the standard well-known URL without waiting on a central directory to list them.