There is a new specification making the rounds that I think deserves attention from anyone working in API governance. It is called the AI Catalog, and it defines a JSON format for discovering heterogeneous AI artifacts — MCP servers, A2A agents, Claude Code plugins, datasets, model cards — through a single discovery mechanism.
The spec is still an unofficial draft, but the design is clean and the problem it solves is real. I want to walk through what it does, why it matters for API governance, and how it connects to what we are building at Naftiko.
The Problem AI Catalog Solves
The AI ecosystem has a fragmentation problem. MCP servers have their own discovery format (server.json in the MCP Registry). A2A agents have agent cards. Claude Code plugins have their marketplace format. Datasets have their own metadata schemas. Each artifact type defines its own discovery mechanism, and clients that want to find and consume these artifacts have to implement bespoke logic for each one.
This is the same problem that APIs had before OpenAPI became the common description format. Every API platform had its own way of describing endpoints, parameters, and schemas. Clients had to learn each one separately. OpenAPI did not replace the APIs — it gave them a common discovery and description layer.
AI Catalog does the same thing for AI artifacts. Each catalog entry declares its artifact type via a media type (application/mcp-server+json, application/a2a-agent-card+json, etc.) and references or inlines the native artifact metadata. The catalog does not wrap or modify the artifact. It provides the discovery envelope.
Three Conformance Levels
The spec defines three levels that let you start simple and add complexity as needed:
Level 1: Minimal Catalog — just a JSON file with specVersion and entries. Each entry has an identifier, displayName, mediaType, and a url pointing to the artifact. This is enough for a team that wants to publish a list of their MCP servers.
Level 2: Discoverable Catalog — adds a host object identifying the catalog operator and supports the /.well-known/ai-catalog.json URI for automated discovery. This is where domain-level discovery becomes possible.
Level 3: Trusted Catalog — adds Trust Manifests with verifiable identity, compliance attestations, provenance tracking, and cryptographic signatures. This is where enterprise governance requirements are met.
The progressive complexity is the right design choice. Most teams will start at Level 1 and never need Level 3. But the teams that do need verifiable trust — and every enterprise API governance team will eventually need it — have a clear path.
Why This Matters for API Governance
API governance teams are about to face a new challenge. It is no longer enough to govern REST APIs, GraphQL endpoints, and event streams. AI agents are consuming APIs through MCP servers. They are communicating with each other through A2A protocols. They are extending IDE capabilities through plugins. Each of these artifact types needs to be discovered, inventoried, governed, and trusted.
Without a common catalog format, governance teams will have to build separate discovery and inventory pipelines for each artifact type. That is the same mistake we made with APIs a decade ago — and it took years to converge on OpenAPI as the common layer.
AI Catalog provides that common layer now, before the fragmentation becomes entrenched. A governance team can maintain one catalog that indexes their MCP servers, A2A agents, Claude Code plugins, and datasets. They can apply trust policies uniformly. They can search across artifact types. They can federate catalogs across departments using collections.
The Trust Manifest Is the Governance Layer
The Trust Manifest extension is where AI Catalog gets interesting for governance. It provides:
Identity binding — every artifact has a verifiable identity (DID, SPIFFE ID, or URL) that binds it to a publisher. You know who published this MCP server. You can verify it cryptographically.
Compliance attestations — SOC2-Type2, HIPAA, ISO27001 attestation documents can be attached to any artifact. When an enterprise needs to verify that an A2A agent meets compliance requirements before deploying it, the attestation is right there in the catalog.
Provenance tracking — where did this artifact come from? What source repository? What digest? Was it built from a CI pipeline with SLSA provenance? The provenance chain is machine-readable and verifiable.
Cryptographic signatures — detached JWS signatures over the Trust Manifest content, using JCS canonicalization for stability. The trust metadata itself is tamper-evident.
This is exactly what enterprise API governance teams need as AI artifacts proliferate. You cannot govern what you cannot discover, and you cannot trust what you cannot verify. AI Catalog provides both.
Collections and Bundles for Scale
The spec includes two organizing mechanisms that governance teams will appreciate:
Collections partition a large catalog into browsable subcategories — Finance Services, Engineering Tools, ML Models — each pointing to a separate AI Catalog at its own URL. This enables federated governance where each department manages its own catalog while the enterprise maintains a top-level directory.
Bundles group related artifacts that are deployed together — an A2A agent that requires a companion MCP server and a dataset. This is dependency management for AI artifacts.
How This Connects to Naftiko
Naftiko capabilities consume APIs and expose MCP tools, REST resources, and agent skills. Each capability is a portable YAML that can be deployed as a container using Naftiko Fleet.
An AI Catalog can index Naftiko capabilities alongside MCP servers, A2A agents, and any other AI artifact type. A capability that exposes an MCP server would appear in the catalog with mediaType: "application/mcp-server+json". A capability that exposes an agent skill would appear with whatever media type the agent skill ecosystem converges on.
More importantly, the Trust Manifest aligns with what we are building for governed capabilities. Identity binding, compliance attestations, and provenance tracking are exactly the governance primitives that enterprises need when deploying AI capabilities that consume production APIs. The AI Catalog provides the discovery and trust layer. Naftiko provides the capability runtime. Together they give enterprises a governed path from artifact discovery to capability deployment.
What to Watch
The spec is still an unofficial draft. The media type (application/ai-catalog+json) is not yet registered with IANA. The link relation (ai-catalog) is proposed but not yet standardized. The OCI distribution mapping is informative, not normative.
But the design is solid. The progressive conformance levels make adoption practical. The Trust Manifest addresses real enterprise requirements without overcomplicating the base format. And the artifact-agnostic approach means the spec does not need to change every time a new AI protocol emerges.
If you work in API governance, keep an eye on this one. The window for establishing a common AI artifact discovery layer is now — before every platform builds its own silo.
