MCP Registry: A Go Service That Indexes MCP Servers for Clients

The gap the registry fills between MCP clients and MCP servers

An MCP client needs to know which servers exist before it can connect to any of them. The README frames the project plainly: it "provides MCP clients with a list of MCP servers, like an app store for MCP servers." That is the whole scope. It is not a runtime, not a transport, and not a proxy. It is a catalog with a publish path and a query path. The audience is therefore narrow and specific. Server authors need a place to register a server so that client developers can find it without scraping GitHub or reading Discord threads. Client developers need one endpoint and one schema instead of a hand-maintained list. Operators who want an internal catalog of approved servers are a third group, and the repository layout supports them because the whole service is self-hostable. If you are looking for a way to run MCP servers, this is the wrong repository. If you are looking for a canonical place to declare that one exists, it is the right one.

What sits inside the Go service: API, auth, Postgres and validators

The documented project structure separates concerns in a way that tells you what the service actually does. Under internal/ there are packages for api (HTTP handlers and routing), auth (described in the README as GitHub OAuth, JWT and namespace blocking), config, database (PostgreSQL persistence), importer (seed data import), service (business logic), telemetry, and validators. Public API types live in pkg/api, with a v0 subdirectory, and the server.json data model lives in pkg/model. Two entry points exist under cmd/: publisher for the publishing CLI and registry for the API server. The data flow implied by that layout is straightforward. A publisher authenticates, the validators check the submitted server.json against the model, the service layer writes it through the database package into PostgreSQL, and clients read it back through the HTTP handlers in internal/api. Namespace blocking in the auth package is the mechanism that stops one account from claiming a namespace it does not own. Deployment configuration lives in deploy/ and is described as Pulumi, which tells you the maintainers run this as infrastructure rather than as a hand-configured VM.

Running it locally with make dev-compose and ko-built images

The README gives a short path. Prerequisites are Docker, Go at the version named in the go directive in go.mod, ko as the container image builder, and golangci-lint pinned to match the version used in .github/workflows/ci.yml. Then one command starts everything: make dev-compose. That brings up the registry on localhost:8080 alongside PostgreSQL. Two details matter for anyone evaluating it. First, the database uses ephemeral storage and is reset on every container restart, so local state does not survive. Second, the default seed pulls a filtered subset of servers from the production API rather than a local fixture, which the README says keeps startup fast and ensures all seed data passes validation. For offline work the README gives an explicit override: MCP_REGISTRY_SEED_FROM=data/seed.json together with MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose. Note that disabling validation is part of that command, so the offline path deliberately skips the check the online path enforces. If you would rather not build, pre-built images are published to GitHub Container Registry with tags latest, main, versioned tags such as v1.0.0, and development tags in the form main-<date>-<sha>. Those images do not bundle PostgreSQL, so you must supply your own and point the registry at it with MCP_REGISTRY_DATABASE_URL. Publishing uses a separate binary: make publisher builds it, and ./bin/mcp-publisher --help is the documented entry point. make check runs lint, schema validation and all tests, and the README warns that it also runs make dev-down, stopping any running dev-compose environment.

Preview status, the v0.1 freeze and the risk of a data reset

The README carries two dated status notes, and they should shape any adoption decision. The 2025-09-08 note says the registry launched in preview and that "breaking changes or data resets may occur." The 2025-10-24 note says the Registry API entered an API freeze at v0.1, that the freeze will hold for a month or more with no breaking changes, and that development continues on v0 while the team validates the API in real integrations and gathers feedback to shape v1 for general availability. Read those together and the constraint is clear. The HTTP surface is stable for now, but the underlying data is not guaranteed to survive, and the freeze is explicitly temporary and scoped to v0.1. For a client that reads the catalog this is tolerable. For anything that treats a registry entry as durable state, such as a lockfile pinning a specific server version, it is a real hazard. The repository also reports the licence as NOASSERTION, which means the material does not identify an SPDX licence. That is a question to resolve by reading the licence file in the repository rather than by inference, and it matters if you plan to redistribute the service or run a modified fork.

Where the registry is the wrong tool

Three cases stand out. First, if you need a private catalog with no external dependency, the default development path seeds from the production API, so the out-of-the-box experience is not isolated even though the service itself is self-hostable. You would need to switch to a file-based seed, and the documented way to do that also disables validation. Second, if you need a version resolution mechanism with guarantees, this is not it. The freeze covers the API shape, not the durability of entries, and the README is explicit that resets may occur during preview. Third, if you want artifact hosting, the registry indexes servers rather than serving their binaries. The container images published to ghcr.io are the registry's own images, not the servers it lists. A team that reads "app store" and expects package distribution will be disappointed by what the API actually returns. The honest summary is that this is a discovery index in preview, and treating it as anything more will produce surprises.

Alternatives and the difference in approach

The most direct alternative is a curated list maintained by hand, which is what many MCP client projects did before the registry existed. The difference is operational rather than conceptual. A hand-maintained list has no auth model, no namespace blocking, no schema validation and no publish CLI, but it also has no preview status, no data resets and no dependency on a third-party service being up. It scales badly and drifts, but it is entirely under your control. The registry trades that control for a shared namespace and a validation pipeline, which is the point of a community registry. A second alternative is to run the registry yourself as a private instance. That keeps the schema, the validators and the publisher CLI while removing the shared namespace and the external availability dependency. The cost is that you now operate PostgreSQL, the deployment configuration in deploy/, and the upgrade cadence yourself. The choice between them comes down to whether you want your servers discoverable by other people's clients. If you do, the shared instance is the only option that achieves it. If you do not, self-hosting gets you the tooling without the coupling.

Upgrade and maintenance cost

The release cadence visible in the repository is steady rather than slow: v1.7.9 in May 2026, v1.8.0 in July 2026 and v1.8.1 in August 2026, with the default branch last pushed in September 2026. That is roughly a release every one to two months, which is a manageable upgrade rhythm for a service you self-host but not a set-and-forget one. The image tags give you a choice of tracking strategies: latest or a versioned tag for stability, main for continuous deployment, and main-<date>-<sha> for pinning an exact commit. Pinning a versioned tag is the only one of those that gives you a reproducible deployment. The development environment resets its database on restart by design, so local data is not something to preserve. On licensing, the reported NOASSERTION value means you cannot treat the terms as known from the metadata alone. Read the licence file before you fork, redistribute or embed the service in a product, and if the terms are unclear, get your own advice rather than assuming a permissive default.

Editorial conclusion

Adopt it if you maintain an MCP server and want a discoverable entry in the index that clients already query, or if you need a self-hosted registry for a private catalog and can accept a preview API. Do not adopt it as a general-purpose package index or as a stable dependency for a product that cannot absorb a data reset. Before committing, read the API freeze note in the README against the v1 work, check the licence file in the repository, and run make dev-compose locally to confirm the seeded subset of production servers matches what your client expects.

Official sources

1. Issues
2. modelcontextprotocol/registry on GitHub
3. Project website
4. README
5. Releases