How AI is applied across API Evangelist and APIs.io. Read my AI disclosure →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

AI Catalog

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.

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 a did:web: identifier), entries, and collections for linking sub-catalogs. It is a static file before it is anything else.
  • Media-typed entries - Each entry declares a type such as application/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 url or inline data, so a catalog can point at a resource or embed its description, but never ambiguously both.
  • Natural-language affordances - description plus 2–5 representativeQueries per entry are what make a catalog searchable by task rather than by keyword.
  • A progressive trust layer - The optional trustManifest holds 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 TXT record can point at the raw JSON, and an SRV record 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.