agentregistry: a self-hosted catalog for MCP servers, agents and skills
Fast-track AI innovation with a centralized, trusted, curated registry
At a glance
- What is it?
- agentregistry is a Go-based registry that puts MCP servers, agents, skills and prompts behind one CLI and web UI, backed by a bundled PostgreSQL instance. It is worth a look if your team already runs Kubernetes and needs a curation layer; it is the wrong tool if you want a managed service or a single-binary install.
- Who is it for?
- Adopt agentregistry if you have a platform team willing to run Docker Compose or Kubernetes and you need an approval gate between public MCP servers and the rest of the company. Skip it if you want a hosted catalog, if you cannot operate PostgreSQL, or if a plain Git repository plus a lockfile already covers your needs.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The scattered-MCP problem agentregistry is aimed at
The README names the problem directly: MCP servers and AI tools are spread across npm, PyPI, Docker Hub, GitHub repos and "random URLs", and nobody knows which ones are trustworthy, which versions work, or how to get them running. The stated consequence is that every developer does their own manual Docker setup and IDE configuration. That is a real coordination cost, not a hypothetical one, and it is the kind of cost that grows quietly until a new hire spends their first week copying config snippets out of a colleague's dotfiles.
The project targets two audiences. For organizations, the pitch is centralized curation: package and publish AI artifacts into one registry, approve agents, servers and skills before company-wide deployment, and attach resource metadata that helps teams judge trustworthiness. For developers, the pitch is the local loop: scaffold an artifact, test it, publish it with one command, then pull and run it anywhere. Those two goals pull in different directions, and the tension between them shows up later in this review.
What actually goes into the registry
Four artifact types are described. MCP servers can be registered from npm via npx, from PyPI via uvx, from OCI or Docker images, or from remote HTTP and SSE endpoints, and each entry supports versioning, environment variables and package references. Skills are described as a SKILL.md bundled with code examples, docs, PDFs and reference URLs. Agents bundle an identity with dependencies: which MCP servers it needs, which skills it uses, and how it should be configured. Prompts are reusable instruction templates, versioned and stored alongside the other three types.
That four-type model is the interesting design decision. Most registries pick one artifact kind and do it well. agentregistry treats a prompt and an OCI image as peers in the same catalog, which is convenient for discovery but means the metadata schema has to stretch across things that behave very differently. The README does not describe how the schema handles that, and that is a gap worth probing before you standardize on it.
The arctl CLI and the apply-based publishing flow
The mechanism visible in the material is a CLI called arctl plus a declarative YAML record. For skills, the README gives this sequence: scaffold with arctl init skill, package and push the image with arctl build ./skill --push, then register the skill record with arctl apply -f skill.yaml. Agents follow the same shape: arctl init agent, arctl build ./agent --push, arctl apply -f agent.yaml.
So the data flow is: source directory to container image to registry record. The build step produces and pushes an image; the apply step writes the versioned record that points at it. That split matters because it means the registry itself is not storing your code, it is storing references and metadata. If your image registry goes away, the records still exist but point at nothing. The README does not state which image registry arctl build pushes to by default, or whether that is configurable, so treat that as something to confirm from the docs before you wire it into CI.
Getting it running: three commands and a Compose file
The prerequisites are Docker Desktop with Docker Compose v2 or later. Installation is a curl pipe into bash from the repository's scripts/get-arctl. Then the README does something slightly unusual: it derives the Compose file version from the installed CLI rather than pinning it, using export VERSION="$(arctl version | awk 'NR == 1 { print $3 }')" and fetching docker/docker-compose.yml from the tag matching that version. Finally docker compose -f agentregistry-compose.yml up -d --wait starts AgentRegistry and its bundled PostgreSQL database.
The UI then answers on http://localhost:12121, and docker compose -f agentregistry-compose.yml down stops the registry while preserving its data. The version-matching step is the part to pay attention to. It keeps the CLI and server in lockstep, which avoids a class of client-server skew bugs, but it also means an upgrade is a two-part operation: install the new CLI first, then re-fetch the Compose file, then restart. The README does not spell out a migration path for the database between versions, and with releases at v0.3.2, v0.3.3 and v0.4.0 within roughly five months, that is a question you want answered before you put real records in it.
Curation and governance as the actual product
The section that carries the most weight is curation and governance, and it is also the section the supplied README truncates mid-sentence: "Turn a broad set of available AI artifacts into a collection your organization is willing to suppo...". The intent is clear enough from the surrounding text, which describes curating and approving agents, servers and skills before company-wide deployment and adding metadata to help teams assess trustworthiness and security.
What is not visible is the enforcement model. The README does not say whether an unapproved artifact is blocked from being pulled, merely flagged in the UI, or something in between. That distinction is the whole value proposition. A registry that labels things as approved but still serves anything is a catalog; a registry that refuses to serve unapproved artifacts is a control. agentregistry is described as the former with governance ambitions, and you should test which one you actually get. The web UI at localhost:12121 is described as the place to review metadata, manage deployments and configure the registry, so the review step appears to be human-driven rather than policy-driven.
Where agentregistry is the wrong tool
The clearest limitation is operational weight. Getting started requires Docker Desktop, Docker Compose v2, and a running PostgreSQL instance that ships in the same Compose file. There is no described single-binary mode, no SQLite fallback, and no hosted option. For a solo developer who wants to try three MCP servers, that is a lot of infrastructure for a discovery problem that a README table could solve.
The second limitation is the pre-1.0 release cadence. The version numbers are still 0.x, and the README's own upgrade instructions tie the CLI version to the server version with no migration guidance. If you are storing records that other teams depend on, a schema change between v0.3.3 and v0.4.0 is a risk you are accepting without documentation.
The third is scope. agentregistry is a catalog and a delivery path, not a sandbox. Nothing in the material suggests it inspects what an MCP server does at runtime, constrains its network access, or audits its behaviour. If your threat model includes a malicious npm package that exfiltrates data through an MCP tool call, a curated registry reduces the number of packages you have to review but does not contain the ones you approve.
How it compares to running your own Git-based catalog
The obvious alternative is a Git repository of YAML files plus a Makefile: one directory per MCP server, a lockfile pinning versions, and a script that writes IDE config. That approach costs nothing to operate, needs no database, and every change goes through code review. Its weakness is exactly what agentregistry is built to fix: no UI for browsing, no versioned artifact store, no consistent pull-and-run command, and no separation between the record and the thing it points at.
The difference in approach is that agentregistry treats the registry as a running service with a REST API, a web UI and a database, while a Git catalog treats it as files. The service gives you discovery and a uniform arctl build and arctl apply workflow across local development and Kubernetes, which the README calls a "consistent path from laptop to cluster". The files give you auditability for free, because the history is the audit log. If your team is small enough that a pull request is a sufficient approval gate, agentregistry is solving a problem you have already solved with less machinery.
Licence, maintenance and what to check first
agentregistry is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. That is a permissive choice with no copyleft obligation on your own code, and it is the same licence used by Kubernetes and most of the CNCF stack, so it will not surprise a legal reviewer. This is a description of the licence text, not legal advice; if you plan to redistribute a modified version, read the NOTICE and attribution requirements yourself.
Maintenance cost is the part the material supports least well. The project is active, with a push in September 2026 and three releases in 2026, and the CLI-plus-Compose upgrade path means every version bump touches both your developer machines and your server. Budget for that as recurring work rather than a one-time install. The thing to verify first is the one the README truncates: how approval is enforced. Stand up the Compose file, publish one artifact through arctl apply, and check whether a second user can pull it before anyone approves it. The answer determines whether you are buying governance or a nicer index.
Editorial conclusion
Adopt agentregistry if you have a platform team willing to run Docker Compose or Kubernetes and you need an approval gate between public MCP servers and the rest of the company. Skip it if you want a hosted catalog, if you cannot operate PostgreSQL, or if a plain Git repository plus a lockfile already covers your needs. Before committing, verify two things in a scratch deployment: that the artifact types you actually use (npm, PyPI, OCI, remote HTTP/SSE) all round-trip through arctl apply and arctl build, and that the bundled Compose file's PostgreSQL volume survives a docker compose down and up cycle.
Community notes