Eleven vendors back ai-catalog.json manifests under their own domains

That sounds like a story about a dead standard. It is not. The plumbing works end to end today, which is a stranger and more useful result than vaporware would have been.

What a catalog has to contain#

The ARD spec defines two things. The first is a static manifest served at the exact path /.well-known/ai-catalog.json on a publisher's own domain. The second is a registry API that crawls those manifests and answers plain-language queries against what it found.

The manifest needs three top-level fields, specVersion, host, and entries. Each entry carries an identifier, a displayName, a type given as an IANA media type, and exactly one of url or data. That is the whole required surface.

Here is a real one, served today, fetched rather than reconstructed from the spec.

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Hugging Face",
    "identifier": "huggingface.co"
  },
  "entries": [{
    "identifier": "urn:air:huggingface.co:registry:discover",
    "displayName": "Hugging Face Discover Registry",
    "type": "application/ai-registry+json",
    "url": "https://huggingface-hf-discover.hf.space",
    "tags": ["registry", "search", "skills", "spaces", "mcp-server"]
  }]
}

Most of the press framed this as a coalition lining up against the two labs that dominate agent usage. That is the wrong model, and it is worth dropping before reading any further. An MCP serverMCPModel Context Protocol, an open standard that lets an AI tool connect to external data sources and services through a shared connector format instead of a custom integration per service.See also .mcp.json route, Extensions directory, Mcp-Session-Id header is one of the payload types a catalog entry can point at, carried as media type application/mcp-server-card+json. Google's announcement describes catalogs as listing "things like MCP servers, A2A agents, OpenAPI tools, or even other nested catalogs".

ARD indexes MCP. It does not compete with it. If you already run a server or two, this is a layer above the one you know, answering a question the Model Context Protocol specification never tried to answer, which is how an agent finds a server nobody told it about.

Trust comes from the domain itself. The publisher segment of each entry's URN has to match a verifiable domain, which is the entire reason the file lives on your host instead of in somebody's central database. The full specification is Apache 2.0 and builds on a data model maintained by a Linux Foundation working group.

How the census ran#

A script fetched https://<host>/.well-known/ai-catalog.json for 44 hosts on July 30, 2026, following redirects and timing out at 15 seconds. The first pass counted a response only if it returned 200 and parsed as JSON, which is a weaker bar than the spec sets.

const r = await fetch(`https://${host}/.well-known/ai-catalog.json`, {
  redirect: "follow",
  headers: { "user-agent": "ard-census/1.0" },
  signal: AbortSignal.timeout(15000)
});

let parsed = false;
if (r.ok) {
  try { JSON.parse(await r.text()); parsed = true; } catch {}
}

So every hit went through a second pass that checked the required fields, specVersion, host and entries at the top level, then identifier, displayName, type and exactly one of url or data on every entry. All three passed with nothing missing. Every use of the word valid below means it cleared that check, not merely that it parsed.

The host list covers all eleven backers at their apex domains, plus their documentation and developer subdomains, plus the two labs absent from the coalition, plus a control group of large SaaS domains, plus three individuals who had blogged about implementing the spec.

Anything that answered 403 or timed out got probed again with a desktop Chrome user-agent and a longer 20-second ceiling, to give slow origins a fairer shot and to separate firewall rules from genuine absence. That re-probe matters more than it looks, and the next-to-last section explains why.

Every host that blocked the crawler blocked the browser too, so those refusals are edge rules rather than user-agent sniffing. ServiceNow failed to answer at 15 seconds and failed again at 20.

Just 3 of the 44 served a valid catalog. 35 returned a hard 404 with nothing at the path at all. 4 answered 403, 1 timed out, and platform.openai.com returned HTTP 200 carrying an HTML page rather than JSON, which the script counted as an absence.

The control group earned its place by being boring. Stripe, Shopify, Atlassian, Slack, Notion, Figma, Vercel and Cloudflare are all companies with public APIs, developer audiences, and every commercial reason to want an agent to find them. None of them serves a catalog either, which suggests the gap is not about the eleven specifically.

One backer of eleven serves a catalog#

The eleven are Google, Microsoft, GitHub, Hugging Face, Cisco, Databricks, GoDaddy, NVIDIA, Salesforce, ServiceNow, and Snowflake, per Search Engine Journal's account, which is the only write-up that enumerates all of them. Google's own announcement says "partners across the industry" and shows a logo wall.

Six weeks in, the results split three ways rather than two.

That third row is not a rounding convenience. Cisco, GoDaddy and NVIDIA return 403 to both a plain client and a desktop browser, and ServiceNow answers neither probe. Whether a catalog sits behind those blocks cannot be established from the outside, and collapsing them into the absent column would make the headline number look worse than the evidence supports.

Hugging Face is the one that moved, and its own launch write-up puts the turnaround at the same week the spec landed. Six weeks later that speed still has no company for it.

One more absence is worth naming. The spec's own site, agenticresourcediscovery.org, returns 404 at the path it defines. So does modelcontextprotocol.io.

The two biggest catalogs belong to individuals#

The other two live catalogs in the census belong to suganthan.com and toddmorourke.com, both independent SEO consultants who wrote up their implementations. Neither signed anything.

Suganthan's manifest runs 2758 bytes across three entries and advertises all three artifact types the spec supports, an A2A agent card, an MCP server card, and an OpenAPI tool. It is the only file in the population that does. O'Rourke's runs 2536 bytes for one MCP server entry, and Hugging Face's runs 520 bytes for one entry pointing at its own registry.

Byte count mostly reflects formatting and how many things got listed, so read the entry counts rather than the sizes. Three entries against one against one still points the same way. The people with the least commercial reason to populate this index are the ones populating it, which is roughly how WebMCP's first year went too.

There is a plainer reading available. Both consultants work in search, both published implementation write-ups the same month, and being early in a sparse index is worth more to them than to a company whose products people already find. That is not cynicism about their motives. It is the entire reason a federated index is worth joining early.

The discovery chain already works#

This is the finding that should change your read of everything above. Follow Hugging Face's catalog to the registry it names, then query that registry, and the whole chain resolves.

curl -s -X POST https://huggingface-hf-discover.hf.space/search \
  -H 'content-type: application/json' \
  -d '{"query":{"text":"pdf"}}'

# 200
# {"results":[{
#   "identifier": "urn:air:huggingface.co:skill:space:lamm-mit:PDF2Audio",
#   "displayName": "PDF2Audio",
#   "type": "application/ai-skill", ...
# }]}

A static file at a well-known path named a registry. The registry answered a plain-language query with a ranked, spec-shaped result. Nothing about that requires a coalition, a launch partner, or permission.

The registry runs as a live service with an OpenAPI document at /openapi.json. Its GET /agents endpoint returns 404, which the spec allows since that one is optional. Send POST /search a bare string and it rejects you with a 422 and a field error naming exactly what it wanted.

So the format is not vapor, and the index is not broken. The index is nearly empty, and those are very different problems to have.

Look at what that chain does not need. No account, no API key, no listing request, no review queue. A registry crawls whatever it can reach at a path it already knows, so the barrier between a working server and a discoverable one is a file you can write in a text editor.

The spec contradicts itself on names#

Every entry needs an identifier, and the identifier is a URN whose publisher segment is what domain verification reads. The spec is not consistent about how that URN starts.

The main specification page uses urn:air: in all eighteen of its identifier examples. The AI Catalog data model page uses urn:ai: in its one example, urn:ai:acme.com:tool:ocr. One stray sample against eighteen.

All three catalogs in the wild have already split along that seam. Hugging Face and O'Rourke emit urn:air:. Suganthan emits urn:ai: across every entry. The host.identifier field diverges too, with Hugging Face using a bare domain and both individuals using a decentralized identifier in the did:web: form.

Three files. Two spellings. Copy the example nearest to hand and which one you land on is decided by which page you happened to open, which is not a great property for the field verification reads.

A population this small makes the crack easy to close, which is the optimistic reading. The pessimistic one is that a divergence rate this high at three publishers is what a draft looks like before anyone has had to interoperate. Nothing has been forced to reconcile yet because almost nothing is talking to anything else.

A firewall can hide your catalog#

O'Rourke's implementation write-up names the failure mode that the census kept running into. "If a web application firewall blocks unfamiliar user-agents, a registry crawler gets a 403 while your browser gets a 200, and you never know".

He also found that cPanel ships a real /.well-known/ directory on disk for certificate renewal, and Apache serves that path straight from the filesystem without ever handing the request to WordPress. Publish through your CMS and the file can be invisible at the only URL that counts.

Four of the 44 hosts held their 403 against a desktop Chrome user-agent as well, so the block sat at the edge rather than in user-agent rules. The practical point survives in a harder form. Loading the URL in your own browser proves nothing about whether the thing this format exists to serve can read it.

Check it the way a crawler would, from outside your network, with a client that looks like a bot.

curl -sSL -A 'ard-census/1.0' -o /tmp/cat.json -w '%{http_code}\n' \
  https://example.com/.well-known/ai-catalog.json \
  && jq -e '.specVersion and .host and .entries' /tmp/cat.json

What the census cannot tell you#

Four of these findings are softer than the rest, and pretending otherwise would be worse than saying so.

• Four hosts are genuinely unknown. Blocked and timed-out domains are reported as their own column rather than assumed empty. If all four are quietly serving catalogs, the backer count is 5 of 11 and the story softens considerably.
• Absence is proven only where the scan looked. Every backer was probed at its apex plus its documentation or developer subdomain, and all of those returned 404 or 403. A catalog on some other host would have been missed.
• One day is not a trend. This is a single snapshot taken six weeks after launch, and the only prior data point is an implementer's observation that three days in, most partner companies had not published one either.
• Nothing here measures the registry side. Whether crawlers are indexing the catalogs that do exist is a separate question the census does not touch.

The subdomain limitation is the one worth sitting with, because it cuts toward the finding rather than against it. A path is only well-known if a crawler does not have to be told which host to try. A catalog reachable only by someone who already knows where to look has given up the property the design exists for.

Whether to publish one now#

Publish if you already run something an agent could call, an MCP server, an A2A agent, or a documented HTTP API, and the cost of one static file and a route is close to nothing to you. Treat it as a cheap bet on a sparse namespace rather than as a distribution channel. Nothing measured here shows that an unconfigured client will find your service today, only that the chain would carry it if one did.

Three things make the difference between a catalog that works and one that just exists.

1. Serve it at the exact path, /.well-known/ai-catalog.json, and confirm it from outside your own network with a bot-shaped client rather than a browser tab.
2. Point entries at things that are already public and already documented. An entry naming a url that needs a credential is an advertisement for something nobody can use.
3. Prefer urn:air: and keep the publisher segment identical to the domain serving the file, then test against whichever registry you care about, because no verifier test in this census settled which prefix interoperates.

Wait if nothing you run is public. A catalog that points at internal services leaks an inventory of your surface area to anyone who fetches a fixed path, and domain-ownership verification is a claim about who published the file, not a control on who reads it.

The thing that decides it is not whether the standard wins. It is whether you have something worth naming. Eleven vendors put their names on this in June, one of them has published a catalog, and two consultants have already built bigger ones than the vendor did, which tells you almost everything about how much permission this needs.

Reach for urn:air: when you write yours. It is what the specification uses eighteen times and what two of the three live catalogs already emit, which makes it the best-supported guess available rather than a settled answer.