Sanjay

Providing visibility and control over 3rd party API integrations in Apps, RPA, Agentic AI Member IETF httpapi working group

8 minute read

The AI ecosystem is fragmenting fast. MCP servers, A2A agents, APIs, Claude Code plugins, datasets, skills, model cards — each one ships with its own metadata format, its own discovery mechanism, and its own trust model. If you’re an enterprise trying to govern what AI your teams are using, or a platform trying to index AI artifacts for downstream clients, you’re implementing bespoke logic for every format. That’s not a protocol problem. It’s a discoverability problem.

discoverability_problem

The AI Catalog spec is a draft standard trying to solve exactly this. It is developed through collaboration among members of the A2A and MCP protocol communities under the governance of the Linux Foundation.

What AI Catalog Actually Is

At its core, AI Catalog is a typed JSON container. You publish a single document — identified by the media type application/ai-catalog+json — and inside it, each entry declares what it is via a media type, and where to find it. One important design principle worth stating upfront: AI Catalog does not replace or redefine protocol-specific artifact formats. MCP server cards, A2A agent cards, and Claude Code plugins remain in their native formats — the catalog provides a common discovery and trust layer around them, not a new schema on top of them.

A minimal catalog looks like this:

{
  "specVersion": "1.0",
  "entries": [
    {
      "identifier": "urn:air:example.com:mcp:weather",
      "type": "application/mcp-server-card+json",
      "url": "https://api.example.com/mcp/server-card"
    },
    {
      "identifier": "urn:air:example.com:a2a:research",
      "type": "application/a2a-agent-card+json",
      "url": "https://agents.example.com/researchAssistant"
    }
  ]
}

That’s it. No mandatory trust infrastructure, no complex schema. A client consuming this catalog knows exactly what each entry is without parsing the artifact itself — the type field does that work.

Who Is This For?

  • AI tool publishers — expose your MCP servers, A2A agents, or plugins through a single discoverable endpoint
  • Platform and enterprise teams — organize and inventory your AI artifact landscape across teams and vendors
  • Registry and marketplace builders — provide a standard discovery interface across artifact types instead of a proprietary format
  • Client and framework developers — write one discovery flow that works for all AI artifact types

Catalog Entry

A Catalog Entry is the core unit of the AI Catalog — each one describes a single AI artifact with a unique identifier, a type, and a URL or inline data payload. Optional fields like displayName, description, tags, version, and updatedAt make entries richer and more discoverable. A publisher object and a trustManifest can be attached when provenance and verifiability matter.

The identifier follows a urn:air:{publisher}:{namespace}:{name} convention for open and federated systems, which keeps identifiers stable across catalog locations and versions.

The type field in a Catalog Entry is the mechanism by which a client knows what it is looking at — without fetching or parsing the artifact itself. It is an open string: any value is accepted, but the spec defines a short list of recognized “known types” (such as application/mcp-server-card+json and application/a2a-agent-card+json) that tooling can act on without additional configuration. Anything outside that list is valid but opaque to generic clients — they’ll pass it through without knowing how to handle it.

The Trust Manifest — and Why It Matters for Enterprises

The Trust Manifest is where the spec gets interesting from a security standpoint.

The key design decision: Trust Manifests sit alongside artifacts as peer elements, not wrapped around them. The artifact’s native format is untouched. That’s important because it means MCP server cards, A2A agent cards, and other formats don’t need to be aware of the trust layer at all.

A Trust Manifest can carry:

  • Identity — a globally unique URI binding the artifact to a verifiable publisher identity (did:web:, spiffe://, domain name)
  • Attestations — verifiable claims including SOC 2 Type 2 reports, HIPAA certifications, publisher identity proofs
  • Provenance — links to the source repository and commit digest the artifact was built from
  • Signature — a detached JWS over the Trust Manifest for integrity verification

The spec also enforces a binding rule: the Trust Manifest’s identity domain must align with the publisher domain in the entry’s URN identifier. Consumers must reject manifests that violate this. That’s a meaningful anti-spoofing control.

For regulated industries, this matters. A catalog entry for an MCP server without a Trust Manifest is just a URL. A catalog entry with a Trust Manifest carrying a SOC 2 attestation and a publisher DID is something you can surface in an audit trail.

Three Conformance Levels

The spec defines a progressive complexity model with three conformance levels:

Minimal — A list of entries with names, types, and URLs. No additional infrastructure required. This is enough to start publishing a discoverable catalog today.

Discoverable — Adds host identity and a well-known URI convention (/.well-known/ai-catalog.json) so that automated clients can find your catalog without being told where it lives.

Trusted — Layered on top via the optional Trust Manifest extension, which adds verifiable identity (DIDs, SPIFFE IDs), compliance attestations, provenance tracking, and cryptographic JWS signatures — all without modifying the artifact’s native format.

This progressive model is the right architectural call. It means a small team can ship a Minimal catalog this week and add Trust Manifest attestations when compliance demands it, without redesigning the whole thing.

Composability and Federation

The catalog format is designed for scale. A catalog entry can reference another AI Catalog (application/ai-catalog+json), enabling hierarchical organization. A top-level enterprise catalog can delegate to sub-catalogs owned by individual teams, vendors, or business units — each independently authored, hosted, and updated.

This federated model is the right fit for the actual structure of enterprise AI sprawl: central security and architecture teams need a single discovery layer, but the artifacts themselves are owned by dozens of teams across Engineering, IT, and external vendors.

Where the Spec Sits Today

AI Catalog is a draft spec — it may change. But the problem it’s solving is real and urgent. As MCP servers proliferate and agentic workflows begin crossing vendor boundaries, the question of “how do we know what AI artifacts are in our environment and whether they can be trusted?” is landing on the desks of CISOs and platform engineering teams right now.

The spec is agnostic about governance — it doesn’t tell you what to do with the catalog, just how to represent it. That’s intentional. The hard work happens on top: who owns the catalog for your enterprise, what attestations do you require before an artifact can be listed, and what does your runtime enforcement layer do when an agent tries to call an unlisted MCP server.

A Notable Gap: API Metadata

One artifact type conspicuously absent from the spec’s list of recognized types is the OpenAPI Description — the most widely deployed machine-readable API format in existence. This matters more than it might seem: enterprises have spent years — and significant investment — cataloging and exposing their capabilities via APIs, with OpenAPI as the de facto description standard. That existing inventory of capabilities is not something AI discovery tooling can afford to ignore. AI agents will increasingly need to call traditional REST APIs alongside MCP servers and A2A agents, and a catalog format that treats OpenAPI descriptions as second-class citizens risks fragmenting the very discovery layer it’s trying to unify.

The OpenAPI Specification since v3.1.1 already references application/openapi+json and application/openapi+yaml as the canonical media types for OpenAPI documents. Those types are the subject of an active IETF draft — REST API Media Types, currently on revision 09 and in IETF HTTPAPI Working Group Last Call as of May 2026. [IANA Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml registration is coming, but it hasn’t landed yet.

Since type is open, nothing stops you from using application/openapi+json in a catalog entry today. For example:

{
  "specVersion": "1.0",
  "entries": [
    {
      "identifier": "urn:air:example.com:api:payments",
      "displayName": "Payments API",
      "type": "application/openapi+json",
      "url": "https://api.example.com/openapi/payments.json",
      "version": "2.3.0",
      "description": "OpenAPI description for the Payments API",
      "tags": ["payments", "fintech", "rest"]
    }
  ]
}

But the absence of these types from the spec’s list of “known types” means tooling won’t treat OpenAPI descriptions as first-class citizens in the discovery layer. Is that intentional? For enterprises that have invested heavily in OpenAPI-described APIs, that’s a real gap: your existing API catalog and your AI artifact catalog speak different languages, at least for now.

This is worth watching. If REST API Media Types lands as an RFC — and the trajectory looks favorable — it would be a natural addition to the AI Catalog’s recognized type list, making OpenAPI descriptions natively discoverable alongside MCP server cards and A2A agent cards in the same catalog. Chime in on issue#82 to support the ask.

A Note on RFC 9727

RFC 9727 (published June 2025) defines /.well-known/api-catalog — a well-known URI for discovering traditional REST APIs using a Linkset format. It’s a published IETF Proposed Standard, but still new and not yet widely adopted. With AI Catalog now offering a broader, artifact-agnostic discovery layer that can potentially index REST APIs alongside MCP servers and A2A agents, RFC 9727 may find itself overtaken before it ever gains real traction — a reminder that in a fast-moving ecosystem, even freshly published standards can be lapped by what comes next.

Enforcement Needs Discovery

Building an AI Catalog is the discovery step. But discovery without enforcement is just a better audit log. The next problem is knowing which of those cataloged interfaces are actually safe — across dimensions like AI-worthiness, trust-worthiness, sensitive data exposure, NHI risk, and policy compliance — and stopping unauthorized flows before they exit your environment. That’s the gap platforms like channelseal are built for: scoring every interface across those dimensions, correlating call metadata without inspecting payloads, and enforcing data privacy control policies inline via an intermediary that runs inside your environment and intercepts outbound agent traffic before it reaches an external MCP server, API, or agents.

Bottom Line

The AI Catalog spec is worth tracking if you’re building AI infrastructure, running a platform that indexes AI artifacts, or trying to govern AI usage in an enterprise. It’s still a draft, but the design decisions — artifact agnosticism, progressive complexity, peer-model Trust Manifests, federated sub-catalogs — are solid.

The ecosystem needs a common discovery layer. AI Catalog is a credible attempt.

Thanks to an AI agent for helping me with research and drafting of this post.

Updated:

You May Also Enjoy

API Discovery Service

5 minute read

Google recently released gws, a command line interface (CLI) for all of Google Workspace. They are describing it as

OpenTelemetry Integration

less than 1 minute read

OpenTelemetry (OTel), is a vendor-neutral open source Observability framework for instrumenting, generating, collecting, and exporting telemetry data such as...

Welcome to channelseal blog

2 minute read

Every modern business runs on integrations. Your CRM talks to your marketing platform. Your payment processor connects to your billing system. Your AI agents...