Agentic Resource Discovery (ARD)

Definition

Agentic Resource Discovery (ARD) is an open specification that defines how AI clients find the tools, agents, and services they can use to complete a task. The things it helps find go by one umbrella term: agentic resources — MCP servers, APIs, Skills, workflows, and other agents. ARD answers a single question on the client’s behalf: what’s available for this job? It returns a set of candidates, each described by what it does, who runs it, where it lives, and how to connect. Then it steps aside.

That last part matters. ARD handles discovery only. It doesn’t run the resource it finds — the client invokes that through the resource’s own protocol, whether that’s MCP, Agent2Agent (A2A), or a plain REST API. ARD sits in front of invocation, not inside it.

The specification was announced in mid-June 2026 and currently sits at version 0.9. Microsoft leads its development, with Cisco, Databricks, GitHub, GoDaddy, Google, Hugging Face, Nvidia, Salesforce, ServiceNow, and Snowflake listed as collaborators — an unusually broad roster for a brand-new standard. It’s published under the Apache License 2.0, and organizations are invited to publish their own catalogs and join the working group.

Marketing relevance

The relevant analogy here is search, and the people behind ARD make it directly. The early web held millions of pages, but most of them stayed dark — there was no way to find anything until search engines built a discovery layer that could reach the whole web and match it to what someone needed in the moment. The agentic web has that same gap right now. A brand can build a commerce agent, expose a product feed to AI, or stand up an MCP server, and none of it counts for much if an AI assistant can’t find it at the moment a shopper asks a question. ARD is the layer meant to make a published capability findable.

For marketers, that sits right next to the work already underway on agent readiness and AI visibility. If a brand’s agent is described in an ARD catalog, an assistant like ChatGPT, Claude, or Microsoft Copilot can surface it on demand rather than waiting for a user to install it by hand. The discoverability problem familiar from SEO — and more recently from share of model — now extends to the tools and agents a brand publishes, not just its written content. A storefront agent that no client can discover is the agentic-era version of a website nobody ever links to.

How It Works

ARD rests on two building blocks: catalogs and registries.

A catalog describes what a provider offers. An organization publishes a static manifest — a file named ai-catalog.json — at a well-known URL on its own domain. The file lists each capability, says what it does, and gives the client a way to reach it. Publishing under your own domain keeps ownership clear, the same way a brand controls its own website.

A registry indexes those capabilities and makes them searchable. It adds richer signals to each entry: publisher identity, example queries a resource handles well, compliance attestations, descriptive tags. It exposes all of that through a REST API. The description side of ARD borrows from a related effort called the AI Catalog standard, which gives one extensible way to describe any kind of resource.

The search interface itself is deliberately small. Only one endpoint is required:

EndpointWhat it doesRequired?
POST /searchFind resources by task — “what can help me do X?”Yes
POST /exploreBrowse and filter a collectionOptional
GET /agentsList a collection’s entriesOptional

A working sequence runs like this. A client sends a natural-language task to a discovery service’s /search endpoint. The service returns ranked matches, each carrying the metadata the client needs to judge fit and connect. The client or the user picks one. The client then connects straight to that resource over its native protocol. Authentication and data access stay between the client and the chosen resource — the discovery service never sits in the path of the actual work.

Federation is built into the protocol. A search run through one service can surface resources hosted by another, using federation modes the spec names auto, referrals, and none. So an enterprise can run a single ARD endpoint that blends approved internal agents with selected vendor and public resources. An employee sees one unified set of answers, and the organization still decides what goes into that set.

How to Utilize

ARD shows up in a handful of distinct ways, depending on whether you’re the one publishing capabilities or the one consuming them.

Make a brand capability discoverable. Publish an ai-catalog.json manifest at a well-known URL describing your commerce agent, shopping assistant, or any MCP server you operate. This is the publishing step a marketing or web team would own, and it’s the prerequisite for any AI client finding the capability later.

Run governed enterprise discovery. Most companies won’t open discovery to the whole web. They’ll build a curated collection — an approved, vetted set of internal tools and sanctioned vendor services — and expose only that. An agent a data team ships on Monday becomes findable by a sales rep on Tuesday, without anyone manually wiring it in.

Select tools at runtime. This is the use case GitHub built for. Its Agent Finder, launched alongside ARD, lets GitHub Copilot discover and call the right MCP servers, Skills, tools, and agents for a task as it works — and it keeps unneeded resources out of the model’s context window, which is its own quiet benefit. Hugging Face shipped a parallel reference implementation called Discover that wraps its Hub search.

Compose multi-agent workflows. Agents can’t collaborate if they can’t locate each other. Cisco’s AGNTCY Agent Directory, an open-source project under the Linux Foundation, implements ARD so agents across teams, clouds, and vendors can find one another and carry their governance rules with them.

Marketing-specific play. A retailer running an agentic commerce storefront can register that storefront’s agent in a discovery endpoint so third-party AI clients reach it directly, rather than routing every shopper through a generic chatbot that may not know the brand exists.

Comparison to Similar Approaches

ARD is often mentioned in the same breath as MCP, A2A, and llms.txt. They solve different problems and mostly stack rather than compete.

ProtocolCore jobWhere it sits in the flowExample
ARDFind the right resource for a taskBefore invocation (discovery)GitHub Agent Finder, Hugging Face Discover
MCP (Model Context Protocol)Connect a client to a tool or server and call itAt invocationAnthropic-originated MCP servers
A2A (Agent2Agent)Let independent agents communicate and delegateAt invocation / collaborationGoogle’s A2A protocol
llms.txtTell AI crawlers which site content mattersContent publishingA site-level llms.txt file

The cleanest way to hold the distinction: ARD finds the resource, MCP and A2A run it, and llms.txt guides crawlers to content rather than to capabilities. A client might use ARD to discover an MCP server, then speak MCP to actually use it. They’re layers, not rivals.

ARD also differs from a traditional app marketplace or plugin directory. A marketplace expects a human to browse, choose, and install. ARD is built for an agent to query in natural language and select dynamically, with the directory feeding the model intent-based results instead of a static catalog page.

Best Practices

  • Publish under your own domain. Host ai-catalog.json at a well-known URL you control. Domain ownership is part of how ARD establishes who provides a resource, and it keeps your brand attached to its own capabilities.
  • Write descriptions for an agent reader, not a human browser. Representative example queries and clear task descriptions are what a registry matches against. Vague marketing copy won’t surface the resource; concrete “this handles X” language will.
  • Scope collections to what you’ve actually approved. For internal use, favor a governed set over the open web. The point of a curated collection is control, so include only resources that have cleared review.
  • Keep manifests current. A discovery layer is only as good as its freshest entry. Stale endpoints and dead capabilities erode trust in the whole collection.
  • Treat discoverability as part of agent readiness. Standing up a commerce agent and never publishing it to a discovery service leaves it invisible to the clients that could route shoppers to it.
  • Don’t conflate discovery with invocation. ARD won’t authenticate users or move data. Plan the invocation path — MCP, A2A, or REST — separately, and design auth around the direct client-to-resource connection.

ARD is early. At version 0.9, with the first reference implementations only just live, several things are still settling.

Expect adoption to track the major AI clients first. Guides already exist for connecting Claude, ChatGPT, GitHub Copilot, Microsoft Copilot, and Gemini to a discovery service, so the consumer-facing assistants are the near-term battleground for which agents get surfaced. For brands, that turns “are we discoverable to these assistants?” into a measurable question rather than a guess.

Federation is the piece most likely to evolve fast. The promise of one search reaching across many services depends on registries agreeing to refer to and trust each other, and the auto / referrals / none modes are an early framework for that. How trust and reputation get verified across organizational lines — who vouches for an unfamiliar agent — is unsettled, and it overlaps with separate work on verifiable agent identity and reputation.

There’s also an open commercial question. ARD deliberately leaves ranking, hosting, and business model out of scope. Whoever ends up running the dominant discovery services will be in a position familiar from search: the entity that decides what ranks where holds real influence over which agents get used. That positions ARD discoverability as a forthcoming optimization discipline, the way SEO grew up around web search.

FAQs

Is ARD a product I can buy? No. ARD is an open specification, not a product or a company. Many discovery services can implement it — GitHub’s Agent Finder and Hugging Face’s Discover are two early ones — and a resource published once should be findable across all of them.

Does ARD run or invoke the agents it finds? No. ARD only handles discovery. Once a client picks a resource, it connects directly over that resource’s own protocol — MCP, A2A, or REST — and the discovery service drops out of the path entirely.

How is ARD different from MCP? MCP is how a client connects to and calls a tool. ARD is how a client finds that tool in the first place. A client often uses ARD to discover an MCP server, then uses MCP to actually work with it.

Who is behind ARD? Microsoft leads development, working with Cisco, Databricks, GitHub, GoDaddy, Google, Hugging Face, Nvidia, Salesforce, ServiceNow, and Snowflake. It’s licensed under Apache 2.0 and open to community contributions.

What does a brand have to do to be discoverable through ARD? Publish a static manifest — ai-catalog.json — at a well-known URL on your domain, describing your capabilities and how to reach them. From there, registries can index and surface them.

Can ARD be limited to internal company tools? Yes, and most enterprises will want exactly that. A collection can be tightly curated to an approved, governed set rather than opened to the public web, while still merging in selected vendor and public resources if desired.

What are catalogs and registries? A catalog is a provider’s published description of its own capabilities. A registry indexes capabilities from many catalogs, adds signals like publisher identity and tags, and exposes a searchable REST endpoint. Catalogs supply; registries make searchable.

Why does this matter for marketing specifically? As shoppers increasingly ask AI assistants to handle tasks, a brand’s commerce agent or product capability has to be findable by those assistants. ARD is the layer that makes that possible, which extends the visibility work marketers already do for search and AI overviews into the world of published agents and tools.

  1. Agentic AI
  2. AI Agent
  3. Multi-Agent System (MAS)
  4. Model Context Protocol (MCP)
  5. MCP Server
  6. Agent Readiness
  7. Shopping Agent
  8. Ad Context Protocol (AdCP)
  9. llms.txt
  10. Share of Model
  11. Citation Optimization
  12. Verifiable Reputation

Freshness note: Agentic Resource Discovery was announced in mid-June 2026 and is at version 0.9 as of this writing. The specification, its endpoints, federation modes, and reference implementations are evolving quickly, and the list of participating organizations may grow. Verify current details against the official specification before implementation.

Sources

Agentic Resource Discovery Specification — official site (Introduction). https://agenticresourcediscovery.org/introduction/

Agentic Resource Discovery — How ARD works. https://agenticresourcediscovery.org/how_ard_works/

Agentic Resource Discovery — ARD Specification (v0.9). https://agenticresourcediscovery.org/spec/

Microsoft Command Line — Introducing the Agentic Resource Discovery specification. https://commandline.microsoft.com/agentic-resource-discovery-specification-ard/

Google Developers Blog — Announcing the Agentic Resource Discovery specification. https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/

Cisco Outshift — How the ARD specification helps agents find each other at enterprise scale. https://outshift.cisco.com/blog/ai-ml/agentic-resource-discover-specification-helps-agents-find-each-other

Snowflake — Snowflake and the Agentic Resource Discovery Specification. https://www.snowflake.com/en/blog/agentic-resource-discovery-specification/

Hugging Face — Agentic Resource Discovery: Let agents search. https://huggingface.co/blog/agentic-resource-discovery-launch

InfoWorld — Solving an ARD problem in AI: Agentic Resource Discovery. https://www.infoworld.com/article/4187305/solving-an-ard-problem-in-ai-agentic-resource-discovery.html

Tags: ,

Was this helpful?