agentclientprotocol/registry: a curated, CI-verified index of ACP agents

What problem the ACP Registry solves, and for whom

An ACP client has to find agents before it can talk to them. Without a shared index, every IDE, launcher or CLI keeps its own hardcoded list of agent names, download locations and version numbers, and each one drifts as agents rename packages or move from npm to GitHub releases. The registry replaces that with one JSON document served from a CDN, so a client reads a list instead of shipping a table of hardcoded URLs.

The audience is narrow and specific. It is the people writing the client side of ACP: IDE plugin authors, terminal front ends, and anyone building a launcher that needs to present a menu of agents to a user. It is not aimed at end users, who never fetch registry.json themselves, and it is not aimed at agent authors who have not implemented authentication, because the README states the registry maintains a curated list of agents that support user authentication and that all agents are verified via CI to return valid authMethods in the ACP handshake. That filter is the project's main editorial decision. An agent that works perfectly but has no auth flow is out of scope, which is a deliberate narrowing rather than a gap.

The index is the product: JSON endpoints and an hourly cron

There is no server process to run and no daemon to configure. The registry publishes static JSON to a CDN, and clients fetch it. The README gives one general endpoint, https://cdn.agentclientprotocol.com/registry/v1/latest/registry.json, plus two JetBrains-specific ones: https://cdn.agentclientprotocol.com/registry/v1/latest/registry-for-jetbrains.json and a preview variant at https://cdn.agentclientprotocol.com/registry/v1/latest/registry-for-jetbrains-preview.json.

The preview index is described as a complete, drop-in replacement for the JetBrains index, where agents without a preview channel appear at their stable version. That design choice matters: a client can swap the URL and keep its parsing code unchanged. The README also warns that preview distributions are not verified, pointing to FORMAT.md for the preview channel details. So the preview channel trades the CI guarantee for freshness, and the documentation is explicit about which one you lose.

Version data is not hand-edited. According to the README, agent versions are automatically updated by a cron job that runs hourly, checking for new releases across npm, PyPI and GitHub releases and committing updates directly to main. The release tags in the repository follow the same cadence, with entries dated 2026-09-14 and 2026-09-15. The practical consequence is that the index moves without a human in the loop, and the commit history on main is the audit trail.

Reading the index from a client

Consuming the registry is an HTTP GET and a parse. The README documents the endpoint and nothing else about client integration, so the only reproducible step it supports is fetching the document and inspecting its top-level keys. What you see depends on the schema in FORMAT.md, which the README points to for the registry schema, distribution types and platform targets.

The README lists the general index URL as:

https://cdn.agentclientprotocol.com/registry/v1/latest/registry.json

If you need the JetBrains view instead, the README lists a separate URL rather than a query parameter, so switching means changing the path.

https://cdn.agentclientprotocol.com/registry/v1/latest/registry-for-jetbrains.json

For the preview channel, the README says the preview index is a drop-in replacement, so the same parser should work, with the caveat that preview distributions are not verified.

https://cdn.agentclientprotocol.com/registry/v1/latest/registry-for-jetbrains-preview.json

The repository itself is not something you install. The top level contains schema files (agent.schema.json, registry.schema.json), documentation (FORMAT.md, AUTHENTICATION.md, CONTRIBUTING.md) and one directory per listed agent, such as claude-acp/, codex-acp/, gemini/, goose/, opencode/ and cursor/. If you want to add an agent rather than consume the list, the README sends you to CONTRIBUTING.md.

What CI verifies, and what it does not

The authentication requirement is the registry's core filter, and the README is precise about how it is enforced: all agents are verified via CI to ensure they return valid authMethods in the ACP handshake. That is a handshake-level check. It confirms an agent answers the protocol correctly and advertises authentication methods. It does not confirm the agent installs cleanly on your machine, that its model backend is reachable, or that a full session completes.

There are two further limits worth naming. First, the preview channel is outside that verification by design, per the README's note that preview distributions are not verified. Second, the repository contains a quarantine.json file at the top level, but the README does not explain what it does, so a client author should not assume it is a machine-readable denylist without checking the schema and documentation. Where the README is silent, treat the behaviour as undefined.

Licensing is similarly split. The registry itself is Apache-2.0, but the README states that individual agents are subject to their own licenses. A curated list under a permissive licence says nothing about the terms of the software it points at.

Where the registry is the wrong tool

If you are building a single-agent product, the registry adds a network dependency and a schema to track for no benefit. Hardcode the one agent you ship. The registry earns its place when the client must present a changing menu of agents it did not write.

It is also the wrong tool if you need a trust or security guarantee. CI checks the ACP handshake and authMethods, not package provenance or sandboxing. Nothing in the README claims the registry vets what an agent does after authentication, and the preview channel is explicitly unverified. Teams that need signed artefacts or reproducible installs will have to layer that on themselves.

Finally, platform coverage is a real constraint. The README defers distribution types and platform targets to FORMAT.md, which means whether a given agent is installable on your OS is a per-entry property, not a registry-wide one. A client that assumes every listed agent supports every platform will produce broken menu entries. The registry tells you what exists; it does not promise it runs where you are.

Registry versus a package manager index

The closest alternative is the package manager an agent already publishes to: npm, PyPI, or a GitHub releases feed. Those indexes are general. They know about versions and artefacts, and nothing about ACP. If you build your client on npm search results, you get every package that mentions the protocol, including ones that never implemented the handshake or authentication, and you own the filtering logic.

The ACP Registry inverts that. It is a small, curated list where the filter is the point: an agent is present because CI confirmed it returns valid authMethods. The trade-off is coverage. A package manager index is larger and updates the moment a maintainer publishes; the registry only contains what has been added and what the hourly cron job has picked up across npm, PyPI and GitHub releases. A brand new agent that has not been contributed will not appear, no matter how well it implements ACP. Choosing between them is choosing between breadth with no protocol guarantee and a protocol guarantee with limited breadth.

Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-15, the same day as the v2026.09.15-3e4dbdd release. Release tags are dated, not semantic: v2026.09.14-fd2cc1d, v2026.09.14-e8d9c55 and v2026.09.15-3e4dbdd all appear within two days, and the suffix looks like a commit identifier. There is no documented compatibility promise attached to those tags, and the README does not describe a rollback path or a versioned migration process for clients.

For a consumer, the upgrade cost is low but not zero. The README points to FORMAT.md for the schema and to registry.schema.json and agent.schema.json in the repository, so a client that validates against those files will notice a breaking change rather than silently mis-parse. The hourly cron means version fields change without a release you can pin to, which argues for validating the document on every fetch instead of caching a parsed copy indefinitely. The registry is Apache-2.0; agents listed in it carry their own licences, and the README does not aggregate or restate them.

Editorial conclusion

Adopt it if you build an ACP client, an IDE integration or a launcher that needs a machine-readable list of agents and their distribution types; the registry.json endpoint is the whole product. Do not adopt it if you need a runtime, a sandbox or a guarantee that every listed agent works on your platform, because the README only promises CI verification of the ACP handshake and authMethods, and the preview channel is explicitly not verified. Before wiring it in, fetch https://cdn.agentclientprotocol.com/registry/v1/latest/registry.json, read FORMAT.md against agent.schema.json, and check whether the agents you care about publish the distribution type your installer supports.

Frequently asked questions

Official sources

1. agentclientprotocol/registry on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases