feat: add application/agent-plugin+json as a recognized catalog entry type

[zeroasterisk]

Add `application/agent-plugins+json` to known types

What

• Adds `application/agent-plugins+json` to the Integrated Ecosystem & Third-Party Types list, referencing the Agent Plugins specification
• Updates the prose example count (three → four AI artifacts) with a new plugin entry
• Adds a plugin entry to `specification/examples/ai-catalog.json`

Why
Agent Plugins is an emerging standard (TSC: Amazon, Cursor, Microsoft, OpenAI, Vercel) for bundling Agent Skills + MCP servers into a single distributable unit. Both constituent types (`agent-skills+json`, `mcp-server-card+json`) are already in the list; this registers the envelope/manifest type alongside them. `+json` suffix is correct per RFC 6838 — `plugin.json` is a JSON object.

Implementation note: discovery, not delivery
Agent Plugins v1 is a filesystem-only format — no HTTP fetch/install mechanism is defined (distribution is in FUTURE_CONSIDERATIONS). A catalog entry's `url` points to `plugin.json` (the manifest), which is the right analogy: the same as `a2a-agent-card+json` pointing at an agent card rather than a running agent, or `mcp-server-card+json` pointing at a server card rather than a running server. The catalog entry enables discovery (read manifest metadata); full execution requires the whole plugin directory via out-of-band delivery (git clone, zip, registry). This is acceptable for catalog purposes.

Choices made

• Third-party placement — governed externally (Agent Plugins TSC, not AI Catalog WG); Core section would be wrong
• Plural `agent-plugins+json` — matches `agent-skills+json` pattern; singular would be inconsistent
• Description: "an Agent Plugin manifest" — precise; `plugin.json` is what the spec calls the manifest; consistent with "an A2A Agent Card" / "an MCP Server Card"
• `url` → `plugin.json` — correct discovery target; same pattern as agent-card and server-card types
• No governance annotation — no existing third-party entry has one; adding here alone would be inconsistent
• No "bundles X+Y" note — redundant with the linked spec

Non-goals

• IANA registration — Agent Plugins TSC's responsibility
• Claude Code plugin support — pre-existing gap in known-types (mentioned in spec prose, no media type listed); separate discussion needed
• Fixing governance annotations across all third-party entries
• Defining a plugin distribution/fetch mechanism — that's Agent Plugins FUTURE_CONSIDERATIONS

Open question for WG — resolve before merge
Agent Plugins spec page says "Working Draft"; GitHub README says "Published". These are materially different. Confirm canonical status with the Agent Plugins TSC.

CI: `uv run --locked python tools/build_spec.py` passes. JSON examples validated.

[darrelmiller]

@zeroasterisk I'm not sure I understand how a consumer will actually be able to use this catalog entry. They may be able to download the plugin manifest, but how can the consumer actually acquire the plugin contents. The readme says that "delivery is out of scope" but what use is discovering a plugin if a consumer has no standard way to acquire it?

[zeroasterisk]

@zeroasterisk I'm not sure I understand how a consumer will actually be able to use this catalog entry. They may be able to download the plugin manifest, but how can the consumer actually acquire the plugin contents. The readme says that "delivery is out of scope" but what use is discovering a plugin if a consumer has no standard way to acquire it?

I believe that, similar to an agent card of mcp card, the plugin is a "card" a manifest of it's own contents which need to be hosted somewhere... like github or whatever.

A compatible client can read the plugin manifest from source, and can "find" that manifest via the ai-catalog.json wrapper.

The agent plugin compatible client is responsible for downloading and using the actual plugin.

The ai-catalog.json is a mechanism to publish a collection or a list of plugins and other types of assets.

[jonathanhefner]

I believe that, similar to an agent card of mcp card, the plugin is a "card" a manifest of it's own contents which need to be hosted somewhere... like github or whatever.

We could look into defining such a card, but right now the only manifest file is plugin.json, which does not specify how to acquire the plugin. (If a client is reading plugin.json, the plugin is assumed to be already acquired.)

I think the right choice here might be for the AI Catalog entry point to an archive (.zip or .tar.gz), and the following plugin.json fields can be propagated into the AI Catalog entry:

• name => displayName
• description => description
• keywords => tags