The AI Catalog Standard is the data model underneath Agentic Resource Discovery — a JSON manifest a publisher hosts at `/.well-known/ai-catalog.json` that lists the agentic resources it offers, whatever they happen to be: MCP servers, agent cards, skills, workflows or plain HTTP APIs. It is artifact-agnostic by design, typing each entry with a media type rather than assuming a protocol, and it carries a progressive trust layer for attestations, provenance and signatures.
AI Catalog
The AI Catalog Standard is the publishing half of the Agentic Resource Discovery
proposal, and it is the part an API provider actually has to do something about. It is worth being
precise about where it comes from: the data model is maintained upstream in a separate project and
GitHub organization (Agent-Card/ai-catalog), and ARD builds upon and extends it with discovery
attributes — domain-anchored URNs, root-level capabilities, representative queries. A provider
publishing a manifest is adopting two specifications at once. ARD defines how a client
searches; AI Catalog defines what a provider writes down. It is a single JSON document at
https://<domain>/.well-known/ai-catalog.json — one more suffix under /.well-known/ —
declaring who the host is and what agentic resources they offer, in a shape that does not care whether
those resources are MCP servers, agents, skills or APIs.
- A manifest, not a protocol - Top-level fields are
specVersion,host(display name plus adid:web:identifier),entries, andcollectionsfor linking sub-catalogs. It is a static file before it is anything else. - Media-typed entries - Each entry declares a
typesuch asapplication/mcp-server+json, which is how one catalog format describes fundamentally different artifacts without collapsing them into a lowest common denominator. - Domain-anchored identifiers -
urn:air:<domain>:<namespace>:<name>ties every resource to the domain that published it, which is what substitutes for a central registry handing out namespaces. - Value-or-reference, strictly - An entry carries exactly one of
urlor inlinedata, so a catalog can point at a resource or embed its description, but never ambiguously both. - Natural-language affordances -
descriptionplus 2–5representativeQueriesper entry are what make a catalog searchable by task rather than by keyword. - A progressive trust layer - The optional
trustManifestholds workload identity binding, compliance attestations (SOC 2, HIPAA, GDPR, ISO), provenance, and JWS signatures — trust as verifiable metadata, kept separate from relevance ranking. - Publishable without infrastructure - If you cannot host the path, a DNS
TXTrecord can point at the raw JSON, and anSRVrecord can point at a live search endpoint.
This is the artifact I would watch across the catalog, because it is measurable in a way that intentions
are not. It sits in exactly the same place as APIs.json and an
Agent Card — a machine-readable index of what you offer, at a path a client can
guess — and the research keeps showing the same thing about that class of file: it costs almost nothing to
publish and roughly three-quarters of providers still do not. An ai-catalog.json is worth writing even
if ARD stays a draft, because the work of enumerating your own MCP servers, agents and APIs with
descriptions a machine can match against a task is the work, and the manifest is just where the answer
gets parked.
Referenced in API Evangelist papers
This standard shows up in my published research. These reports read the machine-readable evidence provider by provider — and put this standard in the context of a real sector.
The ARD Standard
Nine publishers serve an `ai-catalog.json` across 37,751 reachable domains, and four of the nine carry no `representativeQueries` at all — the field that makes semantic search work.