One manifest to describe, install, update and verify an agent extension.

The problem

A memory backend, an MCP server, a channel bridge, a cron job: useful agent capabilities are written every week, and people want them in whatever runtime they already use. Today each runtime has its own plugin format, its own install steps and its own idea of an update. Three groups pay for that:

• Publishers build and maintain one package per runtime, and re-explain what it needs in each one's own words.
• Users paste an install command and hope. Nothing standard tells them who published the thing, what it will touch on their machine, or how it will get updated.
• Hosts, the products that run agents for people, cannot enforce anything they were never told, so every install is a judgement call.

What AXP does about it

The publisher writes one agent-extension.json and signs it. It names the publisher, lists what the extension provides and requires, declares the permissions it uses and why, carries an install recipe per runtime, and says where updates come from. A host fetches the manifest, verifies the signature, shows the user what they are consenting to, hands the right recipe to the runtime, and later accepts an update only if the same key signed it.

AXP is deliberately an envelope, not a package manager. It does not replace a runtime's own install machinery; it delegates to it. It is the common description layer every runtime can be generated from or mapped onto, the role OCI image manifests play across container runtimes. Nothing in the core names a vendor, a product or a registry.

Why not just apt, npm or pip?

Package managers answer a narrower question: how do the files of one ecosystem get onto a machine? An agent extension is seldom one artifact in one ecosystem. The same capability may be a Hermes plugin, an MCP server, a skill folder and a systemd unit, and every runtime wants it registered its own way. No package manager knows what a runtime is, so apt install cannot tell Hermes that a plugin has arrived. Three things they do not carry:

• Consent. A package manager lists dependencies and files. It does not say that the thing reads your secrets, talks to these three hosts or installs a unit as root, let alone why. An npm postinstall runs whatever it likes and declares nothing. AXP states that surface up front, and a widened surface asks the user again.
• Trust. apt and npm trust a registry, and the registry trusts whoever holds the account. AXP binds the signing key to the publisher's own domain, pins it on first use and accepts updates only from the same key. There is no account to take over and no central registry to compromise.
• Updates. A package manager updates when you run it, to whatever the registry holds now. An AXP manifest says where updates come from, on which channel, how fresh a release must be, and that versions only move forward.

AXP does not compete with them; it uses them. An install recipe is free to run pip install, npm install or apt-get. The manifest is the layer above: who signed this, what it will touch, and how it stays current.

How AXP relates to MCP, A2A and plugin systems

They are easy to confuse because they all have "agent" in the name, but they answer different questions and sit at different layers. MCP and A2A are about agents working: an agent calling a tool, an agent handing a task to another agent. AXP is about how the things they work with get onto the machine, stay updated and stay trustworthy, before anything runs.

They stack rather than compete. An AXP package can contain an MCP server (mcp_servers is a first-class component) and an agent installed through AXP can speak A2A. In one sentence: MCP and A2A are how agents work; AXP is how the pieces they work with are shipped.

What the manifest covers

Publish in three commands

The reference implementation ships as the axp Python package and CLI (pip install git+https://github.com/mintbot-ai/agent-extension).

axp init --publisher ext.example.com --name my-ext --description "..."
axp keygen --out signing.key          # prints the ed25519 public key
axp release agent-extension.json --bump patch --artifact dist/my-ext.tar.gz --key signing.key

Serve the manifest from your domain (/.well-known/agent-extension.json or a <link rel="agent-extension"> on your landing page), or attach it to a GitHub release and list your key at /.well-known/agent-extension-keys.json. Then submit the locator here.

Install from the catalog

Every listing shows its locator. On an AXP host you hand that locator to the install command; on mintbot you simply tell your agent "install ext.example.com" and it fetches, verifies, shows the declared permissions and asks before anything runs.

What the catalog checks

Anyone can submit a package. Nothing is listed until it passes the gate, which is the same path a host walks:

1. The locator resolves to a manifest the way SPEC §3.1 says: a .json URL, a landing page's <link rel="agent-extension">, /.well-known/agent-extension.json, or a GitHub repository's newest release asset.
2. The reference validator accepts the manifest in full: identity grammar, every component, every target, permissions with the closed vocabularies of §2.4.
3. The manifest is signed and the signature verifies against the key it carries.
4. The key is bound to the publisher: the manifest was served from the publisher's own domain, or the publisher's key directory lists the key for this extension (§8.5). A code forge is never anybody's origin, so GitHub-hosted manifests are listed through the key directory only.
5. The release is not past its valid_until date. Listings are re-checked against their locator regularly.

The gate judges form, signature and publisher binding, not quality or safety. Read the declared permissions before you install.

Recently listed