Agentic Resource Discovery: Let agents search for tools, skills, and other agents

The last mile of agent tools If you build AI agents today, you’ve probably run into three protocols: MCP for calling tools, Skills for consuming instructions, and A2A for agent-to-agent communication. Each solves a piece of the interoperability puzzle, yet they all sidestep the same question—how does an agent know where to find those tools in the first place?

The current model is “install first, call later.” Developers hardcode MCP server URLs, users connect a plugin to their app. This works for the handful of tools an agent uses every day, but it collapses when you need to handle thousands of ad‑hoc capabilities. You cannot just dump every tool description into the LLM’s context window—it burns tokens and confuses the model.

Agentic Resource Discovery (ARD) is the draft, open specification designed to fix this. It isn’t a product or a marketplace—it’s a shared standard that any company can implement independently, built by contributors from Microsoft, Google, GoDaddy, Hugging Face, and others.

How ARD works—a “phone book” for agents ARD is a discovery layer that sits above existing protocols. It defines two things: a static manifest format called ai‑catalog.json that lets publishers host capability metadata at a well‑known URL, and a dynamic registry API (POST /search) that clients query with natural language to get ranked results.

Think of it like DNS for the internet: instead of remembering IP addresses, you type a domain name and DNS resolves it. ARD gives agents the same kind of resolution. Instead of hardcoding “MCP server at host X,” an agent says, “I need a tool that can translate text,” and the discovery layer returns the best match along with how to invoke it.

Moving selection outside the LLM has another benefit: registries can index capabilities with richer signals—publisher identity, compliance attestations, representative queries—making matches more accurate than relying on thin tool descriptions alone.

The bigger shift: from static integration to dynamic ecosystems ARD signals a paradigm shift. Agent capabilities are moving from manually installed catalogs to intent‑based search that lets agents find the right tool at runtime. Much like mobile apps evolved from built‑in features to on‑demand app store downloads, agent tools are becoming discoverable services rather than hardwired entries in a config file.

In the future, agents won’t just be executors—they’ll be explorers that can search for and adopt capabilities on the fly. If a task requires a tool the agent hasn’t used before, it will be able to discover one that has published an ai‑catalog.json. This fosters a division of labor: tool builders focus on providing capabilities, registry operators focus on indexing and quality, and agents become lighter and more flexible.

What you can do today

• If you build tools or agents, add ai‑catalog.json to your MCP server or A2A agent and register it with an ARD‑compatible discovery service like the Hugging Face Hub. Make your work discoverable.
• If you’re building an agent application, consider adding ARD client logic so your agent can find new abilities at runtime instead of relying solely on pre‑configured tools. This makes your agent more general.
• For product design, ARD suggests a new interaction model: users don’t need to manually connect every service; they just express a need, and the agent discovers and invokes the right capability.

The surprising twist Many people assume MCP and A2A already solved agent interoperability. But discovery is the real bottleneck—having a phone isn’t enough without a phone book. ARD doesn’t invent a new invocation mechanism; it adds the crucial discovery layer that was missing. More subtly, it rejects the idea of making the LLM itself pick from a list of descriptions. Instead, it uses traditional search engineering. That may be a hint: not everything in an agent architecture has to be shoved into a model.