ard.json: the Agentic Resource Discovery manifest and the ai-catalog.json rename

ard.json is the manifest that the Agentic Resource Discovery (ARD) specification asks a site to serve at /.well-known/ard.json. Its entries array lists the MCP server cards, A2A agent cards and skills the site offers, one entry for each. Version 0.91 of the spec, dated 26 August 2026, calls /.well-known/ai-catalog.json the predecessor path and tells publishers to move off it. Lighthouse 13.5.0, the release that added an ARD audit, still reads only the old names.

What is Agentic Resource Discovery?

Google announced ARD on 17 June 2026 as an open specification for finding and verifying tools, skills and agents across the web. The specification names Junjie Bu of Google, R.V. Guha and Shaun Smith of Hugging Face as its authors. It marks v0.91 as a Proposal under the Apache 2.0 licence.

ARD has 2 halves. Publishers host a catalog on their own domain. Registries crawl those catalogs, index them and answer search requests, which the spec defines as POST /search. This article covers the publisher half, because a site owner controls it and a scan can see it.

ARD describes none of the resources itself. Each entry names a media type, such as application/mcp-server-card+json, and the document behind its url follows the MCP or A2A specification. For those formats, read MCP server cards and the A2A agent card example.

Is the file ard.json or ai-catalog.json?

It is ard.json, and the older name is still around. The Google announcement tells publishers to host an ai-catalog.json file at a well-known path. The specification of 26 August names /.well-known/ard.json in section 5.1 and calls the old path and the ai-catalog link relation the predecessor.

The consumer rule has 3 parts. A consumer MUST fetch /.well-known/ard.json and MUST honour a rel="ard" link. It MAY also read the predecessor names, which the spec calls a courtesy to earlier resources and not a conformance requirement. A resource left only at the old path may not be found, so a publisher there SHOULD move.

The spec lists 5 ways to point at entries. They are the well-known URI, JSON-LD embedded in a page, an Agentmap: line in robots.txt, <link rel="ard"> in a page head, and DNS service binding records. It lists no HTTP Link header.

What goes in an ard.json file?

The manifest needs 1 member, entries, and the schema requires nothing else. The spec says ARD ignores any other top-level member. This example follows the entry terms of section 4.2 and the examples of section 4.4:

{
  "specVersion": "1.0",
  "entries": [
    {
      "identifier": "urn:air:example.com:mcp:docs",
      "displayName": "Example docs search",
      "type": "application/mcp-server-card+json",
      "url": "https://example.com/mcp/server-card",
      "description": "Search and read the public documentation of example.com.",
      "representativeQueries": [
        "find the rate limits in the example.com API docs",
        "how do I authenticate with the example.com API"
      ]
    },
    {
      "identifier": "urn:air:example.com:a2a:orders",
      "displayName": "Order status agent",
      "type": "application/a2a-agent-card+json",
      "url": "https://example.com/.well-known/agent-card.json",
      "description": "Answers questions about the status of orders placed on example.com.",
      "representativeQueries": [
        "where is my example.com order",
        "when will order 10432 arrive"
      ]
    }
  ]
}

Each entry takes these terms:

specVersion is not an ARD v0.91 term. It is in the example because the Lighthouse 13.5.0 validator requires it, and the catalog examples of the MCP server card extension carry it. ARD ignores it.

Trust goes in the optional trustManifest. ARD defines no signing scheme of its own, so verification follows the framework the manifest names. The one rule it adds: the domain in trustManifest.identity must match the publisher in the urn:air: identifier.

What does Lighthouse's ard-schema audit read?

Lighthouse 13.5.0 added the ard-schema audit on 18 September 2026 and grouped it with the llms.txt audit under agent discovery, per its release notes. Chrome's agentic browsing documentation has no page for it, so the source is the reference. This section comes from the gatherer, the audit and the validator at the v13.5.0 tag.

The released audit works from the old names:

• It takes the catalog URL from an Agentmap: line in robots.txt, then from a <link> with rel="ai-catalog", then from a Link header with rel="ai-catalog". Otherwise it uses /.well-known/ai-catalog.json.
• It does not request /.well-known/ard.json by itself, and it ignores rel="ard".
• With none of those 3 signals and no 200 at the catalog URL, the audit does not apply. Its code returns notApplicable.
• A catalog that loads goes through the validator, which reports the findings in the next table.
• Any error scores 0. Warnings alone score 0.9. A clean manifest scores 1.

A site that follows v0.91 and publishes only /.well-known/ard.json therefore gets no result in 13.5.0. The same file at the old path, without specVersion, scores 0.

Issue 17251, "ard-schema not updated for ARD v0.91", was opened on 22 September. Pull request 17258 closed it on 9 October. On the main branch, the gatherer now tries rel="ard" and /.well-known/ard.json first and the old names last.

A manifest found only through an old name gets a low-severity warning and a score of 0.9. The validator follows the v0.91 schema, specVersion is optional and collections is a warning.

The releases page listed no Lighthouse version after 13.5.0 on 27 October 2026, so the fix is on main and in no release yet. This is how the 4 readers compare:

In 13.5.0 the <link> and Link header rows apply to rel="ai-catalog" instead.

How does AgenticWebScore check ard.json?

The ARD manifest check is an unscored agent convention marked experimental. It earns no points and gates no level. A site is asked for it only when the scan found an API or agent surface.

The scan requests the manifest that a homepage <link rel="ard"> or Link header points at on the same site. It then tries 4 paths in order: /.well-known/ard.json, /.well-known/agent-resources.json, /.well-known/ai-catalog.json and /ard.json. The last 2 are not in v0.91. The first 2xx JSON document with a non-empty entries array is the manifest.

• Present. Every entry has identifier, displayName and type, plus exactly 1 of url or data.
• Served with an error. An entry lacks one of those terms, an entry carries both url and data, or JSON at a manifest path has no entries.
• Out of scope. The homepage links no manifest and all 4 paths answer 4xx. The Lighthouse audit does not apply in that case either.
• Not measured. A path did not answer, or answered 406 to the scan's Accept header.

The check reads the manifest and nothing it points at. It skips what Lighthouse validates: the urn:air: form of identifier, the media type, representativeQueries and trustManifest.

An entry written for the MCP extension has identifier, type and url, and no displayName, as the extension's own examples show. By the ARD rule it is incomplete, so a catalog of such entries reads Served with an error. The records of 20 October 2026 show that result for github.com and resend.com: 1 entry at /.well-known/ai-catalog.json, 0 complete. The records do not say which term is missing.

The same records show vercel.com with 6 entries at the old path, all complete, which reads present. All 3 manifests the scan read sit at /.well-known/ai-catalog.json.

The record of cloudflare.com shows 404 on all 4 paths, and so does this site's record of 25 October. Both read out of scope, and this site publishes no manifest. MDN was not asked, because the scan found no API or agent surface there.

How do you publish ard.json?

1. Write the file from the example. Add 1 entry for each MCP server card or agent card you serve, with a domain you control in each identifier.
2. Serve it as JSON at /.well-known/ard.json.
3. Add <link rel="ard" href="/.well-known/ard.json"> to the homepage <head>. The spec and this scanner both read it.
4. Decide about the old path. The spec says there is no need to serve it. Lighthouse 13.5.0 and the MCP extension's discovery notes still read /.well-known/ai-catalog.json, so serving the same file at both paths covers every reader for now. Generate both from one source so they cannot drift apart.
5. Check the result with curl:

curl -sS https://example.com/.well-known/ard.json \
  | jq -c '.entries[] | {identifier, displayName, type, url}'

For the example above, that prints:

{"identifier":"urn:air:example.com:mcp:docs","displayName":"Example docs search","type":"application/mcp-server-card+json","url":"https://example.com/mcp/server-card"}
{"identifier":"urn:air:example.com:a2a:orders","displayName":"Order status agent","type":"application/a2a-agent-card+json","url":"https://example.com/.well-known/agent-card.json"}

The spec also describes an official conformance tool in appendix D.4. It validates a manifest, or resolves a domain the way section 5.1 does.

What ARD does not settle

ARD v0.91 is a Proposal. The spec's own note says media type registration is pending and the formats may change.

Whether a registry or an agent product reads ard.json today is not measured here. The 17 June announcement said native ARD support in Google's Agent Platform would arrive in the coming months. This article does not know whether it has. This site's rubric records no effect on Google Search for the check.

A manifest entry is a claim. The card it names still has to be served, and the server behind the card still has to answer. Testing an MCP server with curl covers the second part.

To see how your own site reads, scan it. The methodology lists what each check requests.