What Is the Agentic Resource Discovery (ARD) Specification? ai-catalog.json, Agentmap, and Agent Search Explained

In July 2026, a working group with participants from Google, Microsoft, Hugging Face, and GoDaddy published the Agentic Resource Discovery (ARD) specification — an open standard for how AI agents find tools, APIs, and other agents across organizational boundaries. Protocols like MCP and A2A already define how an agent invokes a capability once it has the URL. ARD addresses the step before that: how does an agent learn the capability exists at all?

The design borrows deliberately from the machinery that made the web searchable — sitemaps, robots.txt, well-known URIs, crawlers — and applies it to agentic resources. This post walks through the moving parts.

The Problem: No Search Engine for Agents

Today, connecting an agent to an external capability means a human found it first: someone read a vendor's docs, copied an MCP server URL into a config file, or hard-coded an A2A endpoint. That works for ten integrations. It does not work for an ecosystem of thousands of agents that should be able to answer "find me a service that can notarize this document" at runtime.

ARD's answer has two halves: a publishing format (how an organization declares what it offers) and a search layer (how registries index those declarations and answer queries).

Publishing: The ai-catalog.json Manifest

An organization publishes one catalog describing everything it offers to agents, hosted under its own domain:

https://example.com/.well-known/ai-catalog.json

A minimal catalog:

{
  "specVersion": "0.1",
  "host": {
    "displayName": "Acme Corp",
    "identifier": "acme.com",
    "documentation": "https://acme.com/developers"
  },
  "entries": [
    {
      "identifier": "urn:air:acme.com:agent:support-assistant",
      "displayName": "Acme Support Assistant",
      "type": "application/a2a-agent-card+json",
      "url": "https://acme.com/.well-known/agent-card.json",
      "tags": ["customer-support", "returns"],
      "representativeQueries": [
        "check the status of my Acme order",
        "start a return for a damaged item"
      ]
    }
  ]
}

The important fields:

Field	Purpose
specVersion	ARD protocol version
host	Publisher identity: display name, domain or DID identifier, docs URL
entries[].identifier	Domain-anchored URN — the stable logical handle for the resource
entries[].type	IANA media type saying what the resource is (an A2A card, an MCP server, an API spec)
entries[].url / data	Exactly one: a link to the resource's own descriptor, or the descriptor embedded inline
entries[].representativeQueries	Example natural-language requests — the raw material for semantic search
entries[].trustManifest	Optional cryptographic claims and compliance attestations

Two design decisions matter here. First, the URN identifier embeds the publisher's domain (urn:air:acme.com:...), so control of the domain anchors the identity — the same trust foundation the web already runs on. Second, identifiers are immutable logical handles while URLs and keys can rotate underneath them, which keeps registry indexes stable as infrastructure changes.

Four Ways to Be Discovered

The well-known URI is the primary mechanism, but the spec defines four, and a thorough crawler checks all of them:

1. Well-known URI — GET /.well-known/ai-catalog.json, following RFC 8615. This is the same pattern OpenID Connect uses for /.well-known/openid-configuration — the pattern that lets a tool like the OIDC Inspector fingerprint any identity provider from a bare domain name.
2. Agentmap directive in robots.txt — a line such as Agentmap: https://example.com/catalog.json, directly mirroring the Sitemap: directive. Crawlers already read robots.txt; now it can point them at your agent catalog too.
3. HTML link tag — <link rel="ai-catalog" href="..."> in a page head, for discovery while crawling ordinary web pages.
4. DNS service binding — DNS records that point at a catalog or search endpoint, for discovery before any HTTP request is made.

Search: Registries and Federation

Registries crawl catalogs and build a semantic index over entry descriptions and representativeQueries. A client queries with natural language:

POST /search
{ "query": "book a table for four in Lisbon tonight", "federation": "auto" }

Results come back with relevance scores (0–100) — and the spec is explicit that relevance is not trust. A high score means the entry semantically matches the query, nothing more.

The federation parameter controls scope: "none" searches only the registry's local index, "auto" lets it merge results from downstream registries, and "referrals" returns pointers to other registries so the client can query them itself. The result is a network of registries rather than one central directory — closer to DNS than to an app store.

Verification: Trust Before Invocation

Before invoking anything a registry returned, a client is expected to verify it:

1. Extract the publisher domain from the entry's URN.
2. Confirm the catalog actually serves from that domain.
3. Validate the entry's trustManifest, if present — cryptographic claims such as SPIFFE workload identity and attestation URIs for certifications like SOC 2.
4. Confirm the workload identity presented at invocation time matches the issuing authority named in the manifest.

This split — registries answer what matches, publishers prove who they are — is what lets the search layer stay open without becoming an attack surface for capability spoofing.

How ARD Relates to MCP and A2A

ARD does not replace either protocol; it indexes them. An ARD entry of type application/a2a-agent-card+json points at (or embeds) a standard A2A agent card. An entry describing an MCP server points at its endpoint or server card. The invocation protocols stay exactly as they are — ARD is the catalog and search layer above them. For the fuller picture of how the three specs divide the stack, see MCP vs A2A vs ARD.

What to Do Now

The spec is weeks old, so live catalogs are still rare — which is precisely why publishing one is cheap positioning. If you already expose an MCP server or an A2A agent, writing an ai-catalog.json that indexes them is an afternoon of work: one JSON file, one Agentmap: line in robots.txt. When registry crawling becomes routine — and with Google, Microsoft, and Hugging Face behind the spec, that is the way to bet — the services already publishing catalogs are the ones agents will find first.