Picture a warehouse stocked with every power tool ever made. Now picture the lights off, no labels, and no inventory list. That’s roughly where AI assistants are today.

Modern AI clients like Claude, ChatGPT, Copilot, and Gemini aren’t limited to what the model knows anymore. They can plug into external tools, MCP servers, APIs, Skills, workflows, and even other agents. The catch? They can’t use what they don’t know exists.

That’s the gap the Agentic Resource Discovery Specification (ARD) is built to close.

Table of contents

• The What: A Search Engine Protocol for AI Capabilities
  • Wait, what’s an “agentic resource”?
  • What ARD is not
• The Why: Discovery Is the New Bottleneck
• The How: Five Moving Parts
  • 1. Describe each resource
  • 2. Build a collection
  • 3. Put a standard search interface on top
  • 4. Search whenever it makes sense
  • 5. Connect it to your chatbot
• Publishing Your Own Tool: Three Steps
• Haven’t We Seen This Before? A Short History of Discovery
  • The family tree
  • The cautionary tale: UDDI
  • What ARD borrows
  • What ARD does differently
• Who’s Behind It?
• The Bottom Line

The What: A Search Engine Protocol for AI Capabilities

ARD is an open protocol that lets an AI client ask one simple question:

“What’s available that can help with this task?”

A discovery service answers with a list of matching resources, telling the client what each one does, who provides it, where it lives, and how to reach it.

Think of it as DNS meets Google, but for AI capabilities.

Wait, what’s an “agentic resource”?

Anything external an AI can call on to get work done:

• An MCP server (e.g., a weather data server)
• A Skill or Plugin
• A plain old API
• A workflow
• Another AI agent

If you can describe it, ARD can help an AI find it.

What ARD is not

This part matters, so let’s be clear:

• It’s not a runtime. ARD doesn’t replace MCP, A2A, Skills, or APIs. It just helps you find the right one. Once found, the resource is called through its own native mechanism.
• It’s not one giant central catalog. There will be many discovery services. A company can run its own private one (like an intranet search engine), and the public web can have several, some focused on quality and trust, others on coverage.

ARD lives entirely in the moment before a tool gets used. It’s the matchmaker, not the date.

The Why: Discovery Is the New Bottleneck

Here’s how AI tooling works today: someone (a user, a developer, an IT admin) has to manually hunt down a tool, decide if it’s trustworthy, wire it into the AI client, and keep that connection maintained.

That’s fine when you have five tools. It falls apart when every vendor, team, and company is publishing their own.

The problems stack up fast:

• The AI can’t use a tool it’s never heard of.
• Users can’t ask for a tool they don’t know exists.
• Enterprises can’t expect every employee to memorize which internal tools, approved vendors, and private workflows fit which task.
• You can’t just dump everything into the AI’s context. Thousands of tool schemas won’t fit in a context window, and even if they did, the model would drown in noise.

Calling tools is a solved problem. Finding the right one is not. ARD tackles exactly that.

The How: Five Moving Parts

1. Describe each resource

Every resource gets an ARD entry: one consistent, extensible format that says what it does, who’s behind it, where it lives, and how to connect. Same shape whether it’s an API or a full-blown agent.

2. Build a collection

Someone gathers entries into a collection. It can be:

• Wide open: anything published on the web
• Tightly curated: an approved, governed set (what most enterprises will want)
• Anything in between

ARD doesn’t dictate what goes in or how it’s ranked. That’s up to whoever runs the service.

3. Put a standard search interface on top

This is the heart of the spec. ARD defines a small, predictable API:

Any collection exposed this way becomes a discovery service, sometimes called an Agent Finder.

4. Search whenever it makes sense

You can search at build time (picking which tools to wire into an agent) or at run time (the agent looks something up mid-task). Your call.

5. Connect it to your chatbot

Your AI client reaches an Agent Finder through a Skill or a remote MCP connector. Ask it to find something, it shows you matches, and you decide what to install. The human stays in the loop.

Publishing Your Own Tool: Three Steps

Want your tool to be findable? It’s refreshingly low-ceremony.

Step 1: Write a manifest called ard.json. Here’s a simplified example:

{
  "entries": [
    {
      "identifier": "urn:air:example.com:server:invoices",
      "displayName": "Example Invoice Assistant",
      "type": "application/mcp-server+json",
      "url": "https://api.example.com/mcp/invoices.json",
      "capabilities": ["CreateInvoice", "LookupInvoice"],
      "description": "Creates and looks up customer invoices.",
      "representativeQueries": [
        "create an invoice for a new client",
        "find last month's unpaid invoices"
      ]
    }
  ]
}

Two fields worth calling out:

• identifier follows a domain-anchored format: urn:air:<your-domain>:<namespace>:<name>. Your domain is your namespace, so no name collisions.
• representativeQueries are 2 to 5 natural-language examples of what people might ask. These power semantic search, so write them like real user requests.

Step 2: Host it at https://<your-domain>/.well-known/ard.json over HTTPS, served as application/json with a permissive CORS header so crawlers can fetch it.

Step 3 (optional): Use DNS. Can’t host at that path? Point a DNS TXT record at wherever the file lives. Running a live search service? Advertise it with an SRV record.

One honest caveat: publishing makes you discoverable, not guaranteed. Each discovery service decides what it indexes.

Haven’t We Seen This Before? A Short History of Discovery

Yes, and that’s a good thing. Every era of computing has eventually needed its own “phone book.” ARD is the latest entry in a long line, and it borrows heavily from the ones that came before.

The family tree

The cautionary tale: UDDI

UDDI is the closest ancestor, and the most instructive. In the early 2000s, web services were going to be “dynamically discovered” from a global registry, a kind of Yellow Pages for software. IBM, Microsoft, and SAP even ran a public UDDI Business Registry.

It flopped. The public registry was shut down in 2006. The schemas were heavy, the registry was centralized, it was tied to one tech stack (SOAP), and in practice developers found services by asking colleagues and reading docs, not by querying a registry.

ARD’s design reads like a list of lessons learned from that story.

What ARD borrows

• A standard description format. WSDL and OpenAPI described how to call a service. ARD entries describe what a resource is for, in a common envelope.
• A search API over a registry. UDDI had an inquiry API; ARD has POST /search.
• Predictable locations. ARD reuses the .well-known convention (the same trick behind robots.txt and OpenID configuration).
• Plain old DNS. ARD’s optional TXT and SRV records are the same building blocks DNS-SD and Bonjour have used for years.
• Crawl-and-index. Publish on your own domain and let indexers come to you, exactly how web search engines work.

What ARD does differently

• The searcher is an AI, not a developer or a load balancer. Older systems looked things up by exact name (“give me payment-service“) or by category code. ARD searches by intent: “what can help me book a flight?” That’s why entries include representativeQueries for semantic matching.
• It’s built for a context window. Previous systems returned everything that matched. An AI can’t swallow thousands of tool schemas, so ARD’s real job is narrowing the field to the few that fit the task.
• It’s stack-agnostic. WSDL only spoke SOAP, and a Consul registry only knows your own services. ARD wraps anything (MCP servers, A2A agents, REST APIs, Skills) using media types, and lets each protocol keep its own details.
• Federated, not central. UDDI wanted one registry; MCP and plugin directories today are each their own island. ARD flips it: describe your resource once on your own domain, and any number of discovery services can index it. Existing registries don’t go away; they just become ARD discovery services.
• Discovery only, by design. UDDI was tangled up with the whole SOAP stack. ARD stops at “here’s what exists.” Authentication, invocation, and installation are left to each resource’s own protocol, with a human typically approving what gets installed.

In short: the idea of a phone book for software isn’t new. What’s new is who’s reading it. ARD takes decades of discovery plumbing and points it at a customer that searches in plain English and has very limited attention.

Who’s Behind It?

ARD is being developed by a working group with participants from Microsoft, Google, Hugging Face, GoDaddy, and others, with contributors including GitHub, Cisco, Databricks, Nvidia, Salesforce, ServiceNow, and Snowflake.

There are already real implementations: GitHub’s Agent Finder, Hugging Face’s Discover, and the self-hostable ANS Finder.

It’s open source under the Apache 2.0 license, and community contributions are welcome.

The Bottom Line

The AI ecosystem is exploding with tools, and nobody can keep track of them all by hand. ARD doesn’t try to be the tool, the runtime, or the one catalog to rule them all. It does one job: help an AI find the right capability for the task in front of it.

Publish once, get discovered by many clients. Search once, find tools well beyond what you already knew about.

Simple idea. Big unlock.