Field data: urn:ai: vs urn:air: at scale, media-type fragmentation, and live-registry conformance

[neuronto]

Findings from operating a federated registry that indexes all four public ARD registries plus the official MCP Registry, currently 9,995 entries from 5,666 publishers. Sharing them because each one silently breaks interop today, and each has a cheap fix at the spec level.

1. Both URN prefixes are live in the wild, at scale

Counting identifier exactly as published, across everything we index:

prefix	entries
urn:air:	8,869
urn:ai:	1,125

The urn:ai: population is dominated by GitHub's Agent Finder (774 of its 782 entries) but is not only them: we also see it from publishers' own /.well-known/ard.json manifests (259) and from WellKnown (56). Since #38/#39 settled on urn:air:, the practical effect is that any client or registry comparing identifiers across sources drops or double-counts about 11% of the ecosystem unless it normalises both.

Suggested fix: one sentence in §the identifier section stating that consumers SHOULD treat urn:ai: as an alias of urn:air: during the transition, or a normative MUST-normalise rule for registries.

2. Media-type fragmentation defeats exact-match filters

The same resource kind is published under several spellings. As written by publishers, across our whole index:

media type	entries
application/mcp-server-card+json	3,882
application/mcp-server	3,605
application/mcp-server+json	356

Filters match exactly, so a client filtering for any one spelling silently loses more than half of the MCP servers in the ecosystem. Same shape as issue #66's question about non-standard types, but this is divergence within the standard kind. A short alias table in the spec (or a SHOULD-normalise for registries) would close it.

3. Conformance reality of the live registries

Ran this repo's conformance tool (v0.9.1) against the public registries on 2026-08-31:

registry	POST /search	GET /agents	POST /explore
GitHub Agent Finder	200	200 but not a paginated object (fails the tool)	400
WellKnown	200, returns referrals only	404	200
Hugging Face Discover	200	404	501
Desvela	200	404	400

Two observations for the spec rather than for those implementations: (a) GET /agents is the least-implemented mandatory surface, and the one place the conformance tool and a major implementation disagree, so an example response in the spec would help; (b) federation: auto is specified as the default mode, but in practice each registry answers only from its own catalogue, and one returns referrals for auto. If auto is intended to mean "the registry merges", a clarifying sentence would make the conformance tool able to test it.

Happy to share the underlying data for any of these counts, and to re-run the sweep if it is useful for a future spec revision. All numbers are from 2026-08-31 and reproducible against the live services.

[neuronto]

Fourth data point for this issue, and the largest one. Measured today by re-probing every publisher our crawler has found, both well-known paths, 2026-09-01.

The ecosystem has not moved to ard.json

Of 178 ARD publishers, checking both paths and requiring the response to parse as a manifest:

path served	publishers
/.well-known/ai-catalog.json	157
/.well-known/ard.json	14
neither, at time of check	7

That is 92% of live publishers on the pre-v0.91 path, including Zapier, ClickHouse, Airtable, Apify, Hostinger and Padlet. The same holds on a named watchlist: of 20 large organisations, the three that publish a manifest at all (Hugging Face, Vercel, Zapier) all serve ai-catalog.json and 404 on ard.json.

Why I am reporting it rather than just handling it

I had a tracker that checked only ard.json. It reported "0 of 20 organisations publish a manifest", and I published that number. It was wrong: the answer is 3. The failure mode is worth naming because any registry or client written against v0.91 alone will reproduce it, and it does not look like an error, it looks like an absence of adoption. A spec-conformant reader currently under-counts real adoption by roughly an order of magnitude.

Suggestion

A normative line stating that consumers SHOULD request /.well-known/ai-catalog.json as a fallback when ard.json is absent, and that publishers SHOULD serve both during the transition, would close it. The <link rel="ard"> / rel="ai-catalog" pair already models exactly this dual naming, so the precedent is in the spec.

Related: this is the same shape as the urn:ai: / urn:air: split above. Both are rename transitions where the spec moved and the deployed base did not, and in both cases the cost of not normalising falls on whoever is trying to read the ecosystem rather than on whoever renamed it.

Happy to share the per-publisher path data if useful for a transition note.