Questions about Agentic Resource Discovery

An open specification that lets an AI agent find tools, skills, MCP servers, APIs and other agents at runtime by describing the job in plain language. Publishers host a JSON manifest on their own domain; registries crawl those manifests and answer searches over them. It sits entirely before invocation and hands off to each resource's own protocol.

Agentic Resource Discovery. Worth writing out at least once in anything you publish, because the three-letter form collides with ARD the German public broadcaster, which owns the acronym in general search.

Google announced it on 17 June 2026. The specification is written by a working group; v0.91 lists Junjie Bu of Google, R.V. Guha of Microsoft and Shaun Smith of Hugging Face as authors, with GoDaddy and others in the group. It builds on the AI Catalog data model from the Linux Foundation's AI Catalog Working Group, and is licensed Apache 2.0.

A proposal. Revision v0.91, dated 26 August 2026, carries the status Proposal in the document itself. It is being developed in the open and has already changed the manifest path once, so build against the version field rather than against memory.

Yes. The specification is Apache 2.0. Publishing a manifest costs you a static file. Individual registries may charge for their own services, but nothing about participating requires paying anyone.

Two groups. If you publish something an agent could call, ARD is how it gets found. If you build agents, ARD is how you stop hardcoding every capability and stop paying context tokens for tools this particular request will not use.

Write a JSON file with an entries array, host it at /.well-known/ard.json over HTTPS with a JSON content type, and make sure it is reachable without authentication. That is the whole process. There is no registration step. Step by step.

No. Publishing is decentralised by design. Any registry that finds your file may index it, and none of them can stop you publishing. That is a deliberate contrast with app stores and package registries.

It depends entirely on the registry, and none of them promise a number. A registry has to discover your domain before it can crawl it, so if nothing links to you, nothing will find you. Submitting your URL to the registries you care about is faster than waiting. The list of registries.

Almost always the missing representativeQueries. Registries rank on those sentences, so an entry without them has nothing to match against and cannot be returned for anything, even though it validates. The other common causes are a manifest that returns HTML with a 200 status, and a publisher segment in the identifier that does not match the domain serving the file.

The url can point anywhere, but the publisher segment of each identifier binds to a domain, and a verifying registry rejects entries claiming a publisher they cannot tie to you. So in practice, describe what you control.

No. trustManifest is optional and most published manifests do not have one. It matters when a consumer needs to verify cryptographically who you are, which usually means enterprise procurement. Add it when someone asks.

One per domain at the well-known path. If you need entries split across files, point at them with <link rel="ard"> or an Agentmap line in robots.txt. Subdomains each get their own well-known path.

Take the entry out of your manifest. Registries that re-crawl you will drop it. How quickly depends on their crawl schedule, and a registry that has stopped crawling you may keep a stale copy, so treat anything you publish as public for longer than you would like.

ard.json. The path /.well-known/ai-catalog.json and the link relation ai-catalog are the predecessor, superseded in v0.91 on 26 August 2026. A consumer may still consult the old path, but is not required to, so a resource that stays there risks not being found. Most of the coverage you will read predates the change. Migration in ten minutes.

identifier, displayName, type, and exactly one of url or data. Carrying both is invalid. Every field explained.

urn:air:<publisher>:<namespace>:<agent-name>, where the publisher is a domain you control. It is a URN rather than a URL so that the handle stays stable when your infrastructure moves.

Two to five. Write the sentence a person types when they have the problem, not a description of your product. Category labels like "document processing" match almost nothing anyone actually asks.

Any IANA media type, in practice application/mcp-server-card+json, application/a2a-agent-card+json, application/ai-skill+md, application/openapi+json and application/ai-registry+json. The specification notes these are de facto community standards still tracking towards formal registration, and asks intermediaries not to verify them strictly yet.

Two things that matter. The manifest moved from ai-catalog.json to ard.json, with rel="ard" replacing rel="ai-catalog". And entries were restated as JSON-LD nodes, which adds a @context seam for other vocabularies without invalidating anything already published. Full changelog.

No. Carrying it is optional, and an entry without one is interpreted by any consumer that applies the base context. You want it when your entry will be read by generic JSON-LD tooling that has not been told it is looking at ARD, which mostly means in-page markup.

MCP is how an agent talks to a tool. ARD is how it finds the tool. They are not alternatives and the great majority of resources in every public ARD index are MCP servers. Side by side.

A2A is a protocol for agents to talk to each other, with an Agent Card describing each one. ARD discovers A2A agents alongside everything else and then hands off. Side by side.

No, and the difference is worth being precise about. llms.txt is a human-readable Markdown file with no schema, no search interface, and no measured evidence that any major system reads it. ARD is a typed format with a required REST search API and working implementations. The comparison.

A directory is a website with a list. A registry is a wire format plus an API, so any client can query any registry the same way and registries can pass queries to each other. A directory can become a registry by exposing POST /search, and some are doing exactly that.

No. Distribution is explicitly out of scope. The specification says mechanisms for physical delivery, OCI, npm and so on, are backend implementation and not part of the discovery record. ARD tells an agent a thing exists and where to reach it, not how to install it.

Not structurally. The MCP registry indexes MCP servers; ARD describes any agentic resource and defines how registries interoperate. An MCP registry can be an ARD registry. The public ARD indexes already ingest MCP registry data.

POST /search with a query object carrying text (required) and an optional filter. You get back entries ranked by relevance, each with at least an identifier. Every registry must expose this endpoint, which is what makes federation possible at all.

auto merges upstream registries' results for you. referrals hands back a list of other registries to query yourself. none searches only that registry. The default is auto.

No, and this is worth being clear about because it gets claimed. Federation means a registry may query others when answering you. It does not copy your entry into them. Each registry crawls independently and applies its own curation. What actually propagates is your manifest, because it sits on your domain where any of them can fetch it.

Yes. Any term an entry carries can be a filter key, including terms from a namespace you declare in @context. A registry that indexes a term makes it filterable, and may reject a filter on a term it does not support with a 400.

A 0 to 100 semantic relevance ranking from the registry that answered. The specification is unusually blunt that it must not be read as a trust, compliance or safety rating.

No. POST /explore and GET /agents are both optional. Only POST /search is required, because federation needs one interface every registry is guaranteed to have.

No. Safety is not something a discovery protocol can compute. What ARD does is let the relevant facts travel: domain-anchored identity, a verifiable trust manifest, signed metadata, provenance. The judgment belongs to the registry that curated the result and the client that checks the signals before connecting.

Discovery is only as permissive as the registry you ask. A curated registry returns only what it chose to index, so nobody can inject an entry into a registry that did not want it. Against the status quo of copy-pasted endpoints with no identity at all, ARD raises the floor rather than lowering it.

Publisher authority binding. The trust domain in trustManifest.identity must match the publisher segment of the identifier, so an entry claiming urn:air:google.com:... is rejected by a verifying registry unless it can produce an attestation issued by google.com.

Very little, measured rather than assumed. Scanning all 97,230 tool descriptions in our index found 74 carrying any model-directed text at all, which is 0.076 percent, with zero override phrasing and zero steganographic codepoints. That is a real answer to a question usually answered with speculation. It is also not a reason to skip sandboxing.

It is a public file on your domain, so treat everything in it as permanently public. Contact addresses in a manifest will be harvested. Do not put anything there you would not put on your homepage.

Paste it, or give a domain, into the validator. It reports errors, warnings and the full list of checks. There is also a conformance tool in the specification's own repository.

Very common, and usually one of two things. Either your endpoint returns 404 for a request method it does not implement instead of 405, which tells a client the endpoint does not exist at all; or it requires authentication for the handshake, which is legitimate but means an anonymous crawler cannot enumerate your tools. Of 8,543 endpoints we introspected, 1,236 returned 404 and 558 returned 405.

Not directly, and be suspicious of anyone who says otherwise. It makes you findable to agents querying registries, which is a different retrieval path from web search. Any traffic effect comes from the page you point at, not the manifest.

It costs ten minutes, so there is no strong reason not to. But the evidence that it changes anything is absent: SE Ranking, Contentful and Mintlify have each looked and found no measurable effect, and Google has said you do not need one. Publish it if you like, do not count it as a lever.

The required surface is one POST endpoint over an index you already have, so the specification's floor is low. What costs money is crawling, embedding and keeping the index fresh. Federation lets a small registry answer beyond its own corpus, which is precisely why it is in the design.

The working group takes issues on GitHub at github.com/ards-project/docs. This site is not the specification and cannot change it; if something here is wrong, that is ours to fix.