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

Dead-standard story? Wrong read. The discovery pipe resolves end to end right now. Empty index, working chain. That combination is more useful than vapor would have been.

Think of the open web as a parking lot full of reserved signs and almost no cars. Logos on the announcement. Nearly nobody parked a file.

What a catalog has to contain#

Two primitives. A static file at the exact path /.well-known/ai-catalog.json on the publisher's domain. And a registry API that crawls those files and answers plain-language search against what it found.

Required top-level fields are specVersion, host, and entries. Each entry needs identifier, displayName, a type as an IANA media type, and exactly one of url or data. Full required surface. Nothing else is mandatory for a pass.

This is a real catalog served today, not a reconstructed sample.

{
  "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"]
  }]
}

Google's post talked partners and showed a logo wall. Search Engine Journal listed the eleven names, and the take that stuck was still "bloc vs labs." Drop that frame. 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 just one payload type a catalog entry can advertise, under media type application/mcp-server-card+json. Google's announcement says catalogs describe "things like MCP servers, A2A agents, OpenAPI tools, or even other nested catalogs".

ARD indexes MCP. Rivalry was never the architecture. If you already run a server or two, this sits above the layer you know and answers a question the Model Context Protocol specification never tried to own. How does an agent find a server nobody put in its config?

Domain ownership is the trust root. The publisher segment of each entry URN has to match a verifiable domain, which is why the file lives on your host instead of in a central directory. The full specification is Apache 2.0.

How the census ran#

On July 30, 2026 a script hit https://<host>/.well-known/ai-catalog.json for 44 hosts, followed redirects, and timed out at 15 seconds. Pass one only required HTTP 200 and a body that parsed as JSON. That bar is weaker than the spec. This part is boring on purpose.

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 {}
}

Every parse hit then went through a second check for the required fields. Top level specVersion, host, entries. Per entry identifier, displayName, type, and exactly one of url or data. All three live catalogs cleared that bar clean. "Valid" in the rest of this post means that check, not mere JSON parse success.

Host list, roughly. All eleven backers at apex, their docs and developer subdomains, the two labs missing from the coalition, a control set of large SaaS domains, three people who had written about shipping an implementation, and that is pretty much the whole map.

403s and timeouts got a second probe with a desktop Chrome user-agent and a 20-second ceiling. Goal was separating WAF rejection from genuine absence, and giving slow origins a fairer shot. That re-probe is load-bearing for the ugly column below, not a footnote.

Hosts that blocked the crawler also blocked the browser. Edge rules, not UA sniffing. ServiceNow failed at 15 seconds and failed again at 20. Same wall, nicer client.

3 of 44 served a valid catalog. 35 hard 404s. 4 answered 403. 1 timed out. platform.openai.com returned HTTP 200 with HTML instead of JSON, counted as absence. A 200 that hands you a marketing page when you asked for a manifest is its own small insult.

The control set was deliberately dull. Stripe, Shopify, Atlassian, Slack, Notion, Figma, Vercel, Cloudflare. Public APIs, developer audiences, every commercial reason to want agents to find them. None serves a catalog either. The gap is not unique to the eleven.

One backer of eleven serves a catalog#

Per Search Engine Journal, the eleven are Google, Microsoft, GitHub, Hugging Face, Cisco, Databricks, GoDaddy, NVIDIA, Salesforce, ServiceNow, and Snowflake. That write-up is the only one that names the full list. Google's own post says "partners across the industry" and shows logos.

Six weeks after launch the backer results refuse a neat present-versus-absent split. Three columns, and the third one is where the story gets honest in a way a binary scoreboard never would.

Sit with that third row. Cisco, GoDaddy, and NVIDIA return 403 to both a plain client and a desktop browser. ServiceNow answers neither probe. You cannot mark them absent without lying about what the packets showed, and you cannot mark them present without inventing a body you never got. Folding the blocked hosts into "absent" would make the headline look worse than the evidence supports. Leaving them out would make it look cleaner than the web actually is.

Hugging Face is the one confirmed publisher among the eleven. Its own launch post says the catalog shipped the same week the spec dropped. Six weeks later, no other named backer has company for that speed. One car in a row of reserved spaces.

One absence is almost funny. The spec site itself, agenticresourcediscovery.org, 404s at the path it defines. So does modelcontextprotocol.io. The document that invents the well-known file does not serve one. Neither does the protocol it is supposed to help agents find.

The two biggest catalogs belong to individuals#

The other two live files sit on suganthan.com and toddmorourke.com. Independent SEO consultants. Implementation write-ups. Zero signatures on the coalition page.

Suganthan's manifest is 2758 bytes with three entries and advertises every artifact type the spec supports (A2A agent card, MCP server card, OpenAPI tool). Only file in the population that does. O'Rourke's is 2536 bytes for one MCP server. Hugging Face's is 520 bytes pointing at its own registry.

Byte counts mostly track formatting and how many things got listed. Entry counts still tell the same story. Three versus one versus one. People with the least corporate stake are the ones filling the index, same pattern as WebMCP's early deployments.

A plainer read works too. Both writers work in search. Both shipped write-ups the same month. Early presence in a sparse federated index is worth more to them than to a company whose products people already find by name. Not a dig at motives. That incentive is exactly why joining early is cheap for you if you already run something public.

The discovery chain already works#

Skip the coalition scoreboard for a second. Follow Hugging Face's catalog to the registry it names, then query that registry.

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", ...
# }]}

Static well-known file names a registry. That registry answers with a ranked, spec-shaped result. No launch partner required. No permission slip.

The registry is a live service with an OpenAPI doc at /openapi.json. GET /agents returns 404, which the spec allows because that endpoint is optional. Feed POST /search a bare string and it 422s with a field error naming what it wanted. The error is almost comforting. At least something is validating input.

Format is real. Index is nearly empty. Those are different problems. The phonebook works. It just has three numbers in it.

Also notice what the chain skips. No account. No API key. No listing form. No review queue. A registry crawls whatever it can reach at a path it already knows. Barrier between a working server and a discoverable one is a file you can write in a text editor. That is not a growth channel. It is a cheap bet that the lot fills in later.

The spec contradicts itself on names#

Every entry needs an identifier. That identifier is a URN, and domain verification reads the publisher segment. The docs do not agree on how the URN starts.

Main spec page uses urn:air: in all eighteen identifier examples. The AI Catalog data model page uses urn:ai: in its one example (urn:ai:acme.com:tool:ocr). Eighteen to one. Still a real split.

Live catalogs already forked on that letter. Hugging Face and O'Rourke emit urn:air:. Suganthan emits urn:ai: on every entry. host.identifier diverges too. Hugging Face uses a bare domain. Both individuals use did:web:.

Three files. Two spellings. Copy the nearest example and which prefix you ship depends on which page you opened first. Bad property for the field verification actually checks. Ship the wrong letter and you may look valid to yourself while a verifier disagrees later.

Optimistic take. Population this small makes the crack easy to close. Pessimistic take. Divergence this high at three publishers is what a draft looks like before anything has to interoperate. Almost nothing is talking to anything else yet, so nothing has been forced to reconcile.

A firewall can hide your catalog#

This is the failure mode that will bite if you ship casually.

O'Rourke's implementation write-up names what the census kept hitting. "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".

Same post documents a second trap. cPanel ships a real /.well-known/ directory for certificate renewal. Apache serves that path from disk and never hands the request to WordPress. Publish through the CMS and the file can be invisible at the only URL that counts. You will open the browser, see a 200, ship the post, and still look dead to a crawler.

Four of the 44 hosts held 403 against desktop Chrome as well. Edge block, not UA rules. Harder form of the same lesson. Loading the URL in your own browser proves nothing about whether a registry can read it. Not even close to a proof.

If your edge treats unknown clients as hostile, you can publish a perfect manifest and still sit in the unprovable column next to Cisco. The file is on disk. The path is right. The world outside your network gets a wall.

Check it the way a registry would. Outside your network. Bot-shaped client.

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

Pass that from a host that is not your laptop. Fail it, and the catalog you think you shipped does not exist for the only audience the format was written for.

What the census cannot tell you#

Several findings are softer than the headline numbers. Naming that is part of the method, not a footnote.

• Four hosts stay genuinely unknown. Blocked and timed-out domains sit in their own column. If all four quietly serve catalogs, confirmed backer adoption is 5 of 11 and the story softens a lot. That is the honest upside, and it still leaves half the coalition empty or silent.
• Absence is proven only where the scan looked. Apex plus docs or developer subdomain for every backer. All of those returned 404 or 403. A catalog on some other host would have been missed.
• One day is not a trend. Snapshot at six weeks. The only earlier signal is an implementer noting that three days after launch, most partner companies still had not published.
• Registry-side indexing is out of scope. Whether crawlers are chewing the catalogs that do exist is a different measurement.

The subdomain limit cuts toward the finding rather than against it. A path is only well-known if a crawler does not need a private map of which host to try. A catalog that only works when you already know the host has abandoned the property the design exists for.

Whether to publish one now#

Publish if you already run something an agent could call (MCP server, A2A agent, documented HTTP API) and one static file plus a route is near-zero cost for you. Treat it as a cheap bet on a sparse namespace, not as a growth channel. Nothing in this census shows an unconfigured client will find you today. It only shows the chain would carry the entry if one did.

Three things separate a catalog that works from one that just exists.

1. Serve the exact path /.well-known/ai-catalog.json, then confirm from outside your network with a bot-shaped client rather than a browser tab. Browser green means almost nothing here.
2. Point entries at things already public and already documented. A url that needs credentials is an ad 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. This census never settled which prefix interoperates in a verifier.

Wait if nothing you run is public. A catalog that points at internal services leaks an inventory of your surface to anyone who fetches a fixed path. Domain-ownership verification claims who published the file. It does not control who reads it.

The deciding question is not whether the standard "wins." It is whether you have something worth naming. Eleven vendors put names on this in June. One confirmed published a catalog. Two consultants already built bigger ones than that vendor. Four more sit behind walls you cannot peer through. Permission was never the scarce resource.

When you write yours, start from urn:air:. Eighteen of eighteen main-spec examples and two of three live catalogs already use it. Best-supported guess available, not a settled answer. And verify the crawl path, or you will ship the file and still look dead to every registry that matters.