Reference

The ARD specification, explained

The document is about 5,700 words and most of the substance is in two sections. This is what each part settles, with the normative sentences quoted rather than paraphrased.

How the document is organised

Six sections and four appendices. Sections 1 to 3 are motivation and principles, section 4 defines the entry, and section 5 is discovery, which is most of the substance. If you are implementing rather than reading, start at 4.2 and 5.3.

Section 3: the principles that explain the rest

Four of the six design principles do real work later in the document, and knowing them makes the rest predictable.

Search-first discovery

The explicit rejection of the app-store model. Rather than pre-installing agents, you find them by searching, and a registry's index updates as things are published. Everything about representativeQueries follows from this.

Scalability beyond context windows

The load-bearing argument. Tool selection by stuffing every description into context does not scale, so selection moves into a dedicated search service where richer signals can be used without spending context tokens.

Artifact-agnostic envelope

ARD refuses to define what an MCP server or an A2A agent looks like inside. It carries a type as an IANA media type and delegates the rest. This is why one format covers five resource families, and why adding a sixth needs no revision.

Universal baseline for federation

Every registry MUST expose a plain HTTP REST search interface, whatever it uses internally. This one sentence is what makes a fifteen-line client work against every registry, and it is the reason federation is possible at all.

Section 4: the entry

Full field-by-field treatment is on the manifest page. Three things in section 4 are conceptual rather than mechanical and are worth reading here.

4.1: an entry is a JSON-LD node

New in v0.91. Terms written plainly belong to a default namespace; an entry may declare @context to draw terms from other vocabularies, and those become filter dimensions without a spec change. The document is careful about what this does not do:

This is a repositioning, not a redefinition: existing manifests remain valid entries unchanged.

ARD specification v0.91, section 1, Overview agenticresourcediscovery.org

4.2: the catalog entry versus the ARD entry

The distinction that explains why valid manifests go unfound. A catalog entry accommodates whatever a publisher wants to say, so it commits to almost nothing. An ARD entry additionally carries the signals a search service needs to compare resources from publishers who have never coordinated. Every ARD entry is a valid catalog entry; the reverse does not hold. The difference is representativeQueries, and it is a SHOULD, so the gap is easy to fall into.

4.5: identity, and what ARD refuses to do

ARD requires only trustManifest.identity and does not define a signing or verification procedure at all. That is delegated to whichever framework the manifest declares: SPIFFE, a DID method, an enterprise PKI. The one rule it does impose is publisher authority binding, and it is the anti-squatting mechanism: an entry claiming urn:air:google.com:... is rejected by a verifying registry unless it can produce an attestation issued by google.com.

A relevance score returned by Search reflects semantic relevance only and MUST NOT be interpreted as a trust, compliance, or safety judgment; trust evaluation is fully decoupled.

ARD specification v0.91, section 4.5.2, Verification agenticresourcediscovery.org

Section 5: discovery

5.1: five ways to publish

The well-known URI, in-page JSON-LD, an Agentmap line in robots.txt, a <link rel="ard"> tag, and DNS service binding records. Recipes for all of them are on the publishing page.

The normative sentence in this section is about resolution, not publishing: a consumer MUST fetch /.well-known/ard.json and MUST honour a rel="ard" link. Consulting the predecessor ai-catalog.json is permitted and optional, which is exactly why staying on the old path is a risk. Migration.

5.2: ingestion

Web ingestion, meaning crawling manifests and in-page markup, is required of every implementation. Scanning git, npm or OCI registries is optional. This is a short section with one consequence worth stating: a registry cannot crawl a domain it has never encountered, so publishing alone does not make you found.

5.3: the search API

The heart of it. One required endpoint, two optional ones.

Two details in 5.3.2 that catch implementers. A search result is not necessarily a complete entry: the registry returns what is useful for choosing, and representativeQueries in particular are normally omitted because they serve indexing rather than display. And the url on a result addresses the artifact, the Server Card or Agent Card, not the ARD entry that describes it.

5.4: federation

auto, referrals or none, with auto the default. How registries compose. What it does and does not mean for a publisher.

The appendices

Skippable unless you are writing tooling. Appendix A is the filter expression syntax, B the standard error codes, C the URN format (urn:air:<publisher>:<namespace>:<agent-name>), and D the formal JSON schemas, including the ardManifest definition that gives the outer document its shape. D.2 is where the conformance tester's warning-versus-error behaviour is defined, which is why a missing representativeQueries warns rather than fails.

Questions

Last reviewed 2026-09-04. Checked against ARD v0.91 (Proposal, 2026-08-26).