AI is only as capable as its wiring allows. Today, a vibe coder, developer, or IT admin has to manually find an agent, MCP server, API, workflow, or other agentic resource judge whether it’s useful and trustworthy, connect it to the AI client, and keep that wiring current. That worked when there were just a handful of well-known agentic resources available. It breaks down when every company, product team, and developer can publish tools of their own.
That’s why we’re introducing the Agentic Resource Discovery (ARD) specification, an open specification that establishes a secure common layer for the publishing, indexing, and discovery of AI capabilities. This, in turn, gives AI clients the ability to tap into new capabilities automatically. Microsoft is developing ARD in collaboration with Cisco, Databricks, GitHub, GoDaddy, Google, Hugging Face, Nvidia, Salesforce, ServiceNow, and Snowflake.
In tandem, GitHub is launching agent finder, a new capability that lets GitHub Copilot dynamically discover and call the right MCP servers, skills, tools, and agents for a given task at runtime. Built on ARD, GitHub’s agent finder gives developers and enterprises control over what AI resources their agents use while simultaneously preventing unneeded resources from bloating the context window. Instead of pre-loading everything, agent finder searches GitHub’s curated catalog of public AI resources or your own private registry, and Copilot finds which resources the prompt calls for and injects them into the context window when you need them.
Hugging Face’s Discover Tool is another reference implementation of ARD, providing search access to thousands of skills, ML applications, and MCP servers on Hugging Face and other ARD discovery services. It provides semantic search across the Hub’s existing ML applications and demos, as well as specialized skills for AI research and development.
Solving the discovery problem
Consider coding agents. A fresh GitHub Copilot installation (without agent finder) exposes a small set of built-in tools. A power developer wires in a few more connectors and works with dozens. That’s the ceiling. Other AI clients expose different tools, with different catalogs and different orchestration, but the basic pattern is the same: Each client can use only the resources that have already been explicitly connected to it. Meanwhile, the ecosystem of available tools already numbers in the hundreds of thousands, scattered across public repos or within an organization’s codebase, and it’s growing by the day. There are orders of magnitude between what any single agent can see and what resources are actually out there. But AI can only use what it’s been explicitly wired to use. Everything else may as well not even exist.
The early internet had a similar problem. Millions of pages existed, but most people only visited the sites that came prefilled in their browser’s bookmarks. The web was there, but it was dark. Some companies tried to solve the challenge with hand-curated directories: categories, subcategories, editorial review. They couldn’t keep up. Search engines solved the problem by building a discovery layer that could reach everything automatically and match it to what someone needed in the moment. Search engines lit the web up.
ARD does the same for the agentic resource ecosystem.
ARD lets an AI client ask one question: What resource can help with a given task? The answer is a set of matching capabilities, detailing what each one does, who provides it, where it lives, and how the AI client can reach it. The AI client invokes the resource it selects through that resource’s own protocol: an MCP, an API, a workflow system, or something else. ARD sits before invocation—it helps the AI client decide which capability to use.
Think of it like a search engine, of resources for AI clients. A developer publishes a lightweight manifest describing what their resource does. That manifest is crawled and indexed, much like a web page. When an AI client needs a new capability, it describes the task in natural language, and ARD returns the tools that can help—along with everything needed to invoke them. A developer may have published a tool just last week, on the other side of the world, for exactly the problem someone else is facing right now: ARD connects them without building custom integrations for each ecosystem.
How discovery differs from search
It’s tempting to think that ordinary search could solve the problem. But it can’t.
Web search worked because the web already had a discoverable surface: Pages linked out to other pages, HTML described content in a form that browsers could render, and HTTP gave crawlers and browsers a common way to retrieve that content. Search engines didn’t have to invent that surface: They built on top of one that already existed.
Agentic resources have had no equivalent surface to date. A name and URL aren’t enough. To discover a resource safely and usefully, an AI client needs structured information about what the resource does, when it should be used, what inputs it accepts, what authority it requires, who operates it, how it is invoked, and whether it is appropriate for a given user, organization, or policy environment.
Without a common way to express all that, discovery falls back to manual wiring, private catalogs, ad hoc registries, and hard-coded integrations—none of which scale. ARD gives these resources the discovery surface they’ve been missing.
Beyond a single catalog
The goal isn’t a single global catalog of every resource. There will be many discovery services, each defined by what it indexes, whom it serves, and how it ranks. Some may optimize for coverage while others optimize for quality or a particular domain. ARD helps AI clients discover capabilities, but it doesn’t replace authentication, authorization, governance, or organizational trust decisions.
An AI client gets different answers depending on which discovery service it asks. That isn’t a flaw—it’s the point. Different users and organizations need different answer sets: A public service may include resources from across the web, a vendor service may expose a single ecosystem, and an enterprise service may expose only internal resources, paid vendor services, and vetted third-party capabilities.
Whoever runs the discovery service controls the answer set. That is what makes the enterprise case important.
We’re leading with an open specification because we want to encourage open ecosystems. Not walled catalogs. Not curated directories that can’t keep up. Again, think of the web model: publish, be discovered, get used.
We want to encourage open ecosystems. Not walled catalogs.
Discovery services shouldn’t have to be isolated. A company may want one view that includes its private resources, selected vendor resources, and selected public resources; a public service may index many publishers; a specialized service may index a single ecosystem. ARD allows for all three scenarios.
This gives ARD an architectural property closer to DNS than to ordinary web search. DNS allows local control while still participating in a larger shared system—an organization resolves private names and public names through the same resolver. Web search has no equivalent: You query one engine’s index, with no standard way to say, “Give me these results plus my company’s private results, merged.”
Like DNS, ARD applies a similar idea to capabilities: local control, upstream sources, and a larger ecosystem that organizations can join without giving up control. The analogy isn’t exact (DNS resolves names while ARD returns ranked capability matches), but the control model is similar.
As the ecosystem of agents, MCP servers, APIs, and other agentic resources grows, discovery becomes a foundational challenge for any of them to work at scale. ARD is an open effort to create a common discovery layer that lets AI clients find and use capabilities dynamically—regardless of who built them or when.
Get started with ARD today
For instructions on how to expose your resources to ARD services, click here. To learn more, check out the full spec.