One manifest to describe, install, update and verify an agent extension.
The Agent Extension Protocol (AXP) is a runtime-neutral standard for packaged agent capabilities: memory backends, MCP servers, tools, channels, services, skills, prompts, panel views. A publisher writes one signed agent-extension.json; any host that speaks AXP can install it, keep it updated and know who signed it.
An envelope, not a package manager
AXP 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.
Portable description
identity (publisher-namespaced), provides (what the extension adds), requires (what it needs) and permissions (the access surface it declares, with reasons). A user can read what they are consenting to before anything runs.
Per-runtime targets
Concrete install recipes per runtime plus a posix baseline any host can execute: an archive, a digest and standalone install / upgrade / uninstall / health scripts with a fixed host-to-script contract.
Safe updates
Semver and channels, three update sources (GitHub releases, a forge, a direct feed), monotonic progression, freshness windows and a per-extension policy. A widened permission surface asks for consent again.
Signing and trust
ed25519 signatures over a canonical (JCS) form of the manifest, pinned on first use per extension id. Updates come only from the same key; rotation is announced and dual-signed; a lost key is recovered through the publisher's key directory.
Honest enforcement
A host says which tier it really applies - declared, advisory or enforced - and conforms to a profile (Core, Trusted, Managed, Sandboxed). The reference sandbox runs lifecycle scripts in transient systemd units with name-based egress filtering.
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:
- The locator resolves to a manifest the way SPEC §3.1 says: a
.jsonURL, a landing page's<link rel="agent-extension">,/.well-known/agent-extension.json, or a GitHub repository's newest release asset. - The reference validator accepts the manifest in full: identity grammar, every component, every target, permissions with the closed vocabularies of §2.4.
- The manifest is signed and the signature verifies against the key it carries.
- 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.
- The release is not past its
valid_untildate. 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
| Package | Version | Provides | Runtimes | Publisher |
|---|---|---|---|---|
| Claude Shim Use your Claude Code subscription as a Hermes LLM provider. |
1.26.4 |
model_providers | hermes | aiaininja.com |
| mintbot MCP server An MCP server on the agent's own VPS: chat with the agent and manage every mintbot setting (model, persona, name, credit, jobs, extensions, Telegram bot, updates, SSH keys, two-factor) from any MCP client such as Claude Desktop, Claude Code or Cursor. No central server involved; loopback only, bearer-authenticated. |
0.1.1 beta |
services | hermes | mintbot.ai |
| Graph Memory Temporal knowledge-graph long-term memory using the agent's selected Hermes model for extraction, local FastEmbed vectors for semantic recall, and embedded LadybugDB, the maintained continuation of Kuzu. |
0.2.0 beta |
tools, memory, config | hermes | mintbot.ai |