Agentic Resource Discovery and resource catalogs

Resource catalogs describe the agent-facing interfaces a site exposes. This guide distinguishes ARD revisions, earlier AI Catalog conventions and the resources those manifests point to.

Agentic Resource Discovery, or ARD, is an open specification for telling AI agents what a site offers, in one machine-readable file. Instead of inferring from pages whether a site has an MCP server, an agent interface or an API, the site publishes a single index that names each resource and where to reach it. The specification appeared in 2026, is licensed under Apache 2.0, and builds on the AI Catalog data model maintained by a working group under the Linux Foundation, as its June 2026 announcement states.

What the manifest contains

A site advertises its agentic resources by serving a static JSON manifest under /.well-known. ARD v0.91, published 26 August 2026, names the file /.well-known/ard.json and the link relation ard, and says a conformant client MUST read that path. The predecessor path /.well-known/ai-catalog.json and the relation ai-catalog are ones a client MAY also consult, so a site that serves only the old path may not be found by a client that follows the current revision.

The current specification defines the manifest itself as a JSON document holding an entries array. Other top-level members, such as the specVersion and host fields the predecessor AI Catalog convention still carries, are transport-defined and ignored by ARD. Each entry describes one resource with a stable identifier, a display name, a type and a url or inline data. A resource can be an MCP server, an A2A agent, an API or a skill set. A registry can crawl published catalogs and answer a capability query by pointing an agent at the right resource.

Where it sits, and how it differs from llms.txt

ARD is a discovery layer, not a transport. It helps an agent find the right resource, which the agent then calls through that resource's own protocol, whether MCP, A2A or a plain API. Discovery comes first and invocation second. The catalog does not replace the manifests it points to, it indexes them, so a site keeps its server card, its agent card and its OpenAPI description, and adds one file that ties them together.

llms.txt tells an agent where a site's content lives. An ai-catalog or ard manifest tells an agent which agentic resources the site exposes and how to reach them. The two are complementary, and neither is a ranking file. Google has said publicly that llms.txt does not affect its search results, and the same holds for a resource catalog: neither changes ranking in Google Search. That is a statement about Google Search specifically. An ARD registry is a different kind of index: it crawls published catalogs and answers a capability query over them through its own required search API, so these files are read by agents that act and by the registries that index them for that purpose, not by a general web search index.

Draft status and how to validate a manifest

The specification is early. As of September 2026 the repository carries a versioned draft, v0.91, and a normative change to the spec or its schemas starts as an issue before a maintainer lands it. Publishing a manifest today still means validating it against the draft revision the client you care about actually reads, rather than assuming one fixed shape.

What a scan checks, and why it matters now

A technical scan can check whether a manifest resolves at the declared path, parses as valid JSON and names entries with a url that answers. A manual review reads whether those entries point at resources that actually work, and whether the descriptions match what the resource does. Neither checks whether an agent has found the catalog through observed use, which is a separate question from whether the file exists and parses.

Adoption is early. In a June 2026 check against public well-known paths, none of the launch partners the announcement shows yet served a discoverable ai-catalog.json, so publishing one now is a forward move rather than table stakes. The value is the same as every other discovery surface. A capability an agent cannot find is a capability that does not exist for that agent, and one predictable file turns a set of separate manifests into a single answer.

turva.dev serves the same entries at both paths, /.well-known/ard.json with the MCP Server Card media type on its MCP entry and rel="ard" in every page head, and /.well-known/ai-catalog.json for clients and scanners that still read the predecessor. Both index its MCP server, its A2A agent, its API and its agent skills, each of which already resolves on its own. The separate experimental MCP Server Card discovery document keeps its own convention, an AI Catalog at /.well-known/ai-catalog.json, so the two profiles are described apart and not merged. For an audit of a site's discovery surface, contact info@turva.dev.

Sources

• ARD specification repository
• Google announcement of Agentic Resource Discovery
• Server Card discovery document, the AI Catalog side

Related

• The /.well-known directory for agent discovery
• MCP server cards and discovery
• Agent commerce discovery: A2A, AP2, ACP and UCP