# The Docker MCP registry is a catalog where images come with provenance > The Official Docker MCP Registry is a curated catalog of Model Context Protocol servers that appear in the Docker Hub MCP catalog, the Docker Desktop MCP Toolkit and the mcp namespace, with Docker-built images signed and shipped with SBOMs. Contributing to it means a pull request, not a code change. **docker/mcp-registry** — Official Docker MCP registry - Repository: https://github.com/docker/mcp-registry - Stars: 574 · Forks: 2,184 - Language: Go - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/docker-mcp-registry ## A catalog, not a runtime The Official Docker MCP Registry is described as a curated catalog of MCP servers that can be discovered, deployed and integrated with any MCP client and compatible with Docker tooling. The framing matters for what the repository is. It is not a runtime, it is not a client, and it is not a gateway. It is a list of metadata with an approval process attached, and the entries it holds surface in three places: the MCP catalog on Docker Hub, Docker Desktop's MCP Toolkit, and the Docker Hub `mcp` namespace for the servers Docker builds itself. The Model Context Protocol itself is described as an open standard that lets AI assistants connect securely with external data sources and tools. So the registry sits at the supply chain layer of the MCP ecosystem. Its job is to decide what is trustworthy enough to put in front of an assistant, and its output is a set of images with metadata and, in the preferred path, a signature. ## Why the registry exists at all The README gives the reasons as a short list, and the order tells you which one matters most. Enterprise security comes first, because the servers Docker builds include cryptographic signatures, provenance tracking and Software Bills of Materials for trust and compliance. Container isolation is second, because all MCP servers run in isolated containers, protecting the host from vulnerabilities in the server. Curated quality is third, since all servers undergo review against quality and security standards. Then easy discovery, where you browse for servers matching a use case or share yours to millions of developers through Docker tools, and Docker integration for deployment with containers. The isolation point deserves emphasis for anyone evaluating this. An MCP server is a program an assistant can call, and running it in a container is the practical containment boundary. The registry's curation is about what the server is; the container is about what it can touch. ## Contributing is a pull request with metadata The contribution model is the part that surprises people who expect a code submission. To add a server you submit a pull request with the metadata information, and the CONTRIBUTING guide has the detailed instructions. Once approved, the entry is added to the MCP catalog, to Docker Desktop's MCP Toolkit, and, for images built by Docker, to the `mcp` namespace on Docker Hub. The repository supports two submission types. Option A, a Docker-built image, is the recommended path: you submit the required information via pull request and Docker builds, signs and publishes your image to `mcp/your-server-name` on Docker Hub, with the catalog entry available within 24 hours. The benefit listed is that your image includes cryptographic signatures, provenance tracking, SBOMs and automatic security updates. Option B is a self-provided pre-built image, which is used directly in the catalog. The note on that path is honest about the difference: self-built images still benefit from container isolation but do not include the enhanced security features of Docker-built images. ## The compliance list is short and the enforcement is real There is a stated standard every server in the registry must meet, and it reads like a checklist for a hosted service rather than a hobby project. Servers must follow security best practices, include full documentation, provide working Docker deployment, maintain compatibility with MCP standards, and include proper error handling and logging. The README is explicit that non-compliant servers will be reviewed and may be removed from the registry. The point of writing that down is that a registry without a removal policy is a link dump, and a registry with one is a curation process that implies ongoing review of what is already listed. It also implies that the compliance bar is only as good as the review behind it, which the documentation does not describe in detail. There is no stated review turnaround for existing entries, and the process for changing or removing a server is an issue rather than a pull request, which is a reasonable channel for that kind of request. ## What the Go codebase in the repository actually is The repository is written in Go, and the module is `github.com/docker/mcp-registry` on Go 1.24.0. The top-level layout tells you it is tooling rather than the catalog data itself, with a `cmd/` directory for the command entry points, `internal/` and `pkg/` for the implementation, a `servers/` directory, an `agents/` directory, `scripts/`, `docs/`, and a `Taskfile.yml` for task automation. Two dependencies explain the shape of the tool. `mark3labs/mcp-go` at 0.25.0 is the Go implementation of the protocol itself, so the registry tooling speaks MCP natively. And the Charm library set, `huh` and `lipgloss` along with bubbletea and bubbles, is a terminal user interface kit, which means the tool presents an interactive terminal UI rather than only reading and writing files. The remaining direct dependencies are `spf13/cobra` for the command structure, `gopkg.in/yaml.v3` for the metadata format, and `google/go-github` for talking to GitHub. The metadata files the contributions describe are YAML, and the pull request is a metadata pull request, which is why the tool needs an MCP client library and a terminal UI rather than an image builder. ## Two ways to consume an entry, and the gap between them The practical difference between Option A and Option B is the supply chain assurance, and it is worth being concrete about the gap. A Docker-built image is built and signed by Docker, carries provenance tracking so you can see where it came from, ships an SBOM so you can enumerate its contents, and receives automatic security updates. A self-provided image is one you built and you are responsible for, and while it still runs in an isolated container, the signature, the provenance and the SBOM are not there. That is a meaningful difference for an organisation with a software supply chain policy, and it is also the reason the recommended option is recommended. The catalogue listing and the image are therefore not the same thing in terms of trust, even though they look identical to a user clicking through Docker Hub. The registry does not verify what an MCP server does for you, it verifies the process by which the image was produced. The MIT licence covers the registry project itself, and the licence for any individual server image is a separate matter to check in its catalogue entry. ## Conclusion Adopt the Docker MCP registry if you want MCP servers that arrive with cryptographic signatures, provenance and an SBOM rather than an opaque image reference, and you deploy through Docker tooling. Skip it if you need an unvetted server that is not in the catalog, since a registry is a filter, and skip it if you have no way to run containers, because every entry depends on container isolation. Before you rely on an entry, read the catalog listing for the specific server rather than trusting the registry's review to cover the tool it wraps. ## FAQ ### What is the Official Docker MCP Registry? It is a curated catalog of Model Context Protocol servers that can be discovered, deployed and integrated with any MCP client and Docker tooling. Entries appear in the Docker Hub MCP catalog, Docker Desktop's MCP Toolkit, and the Docker Hub `mcp` namespace for servers Docker builds. ### How do I add an MCP server to the Docker registry? You submit a pull request with the metadata information, following the CONTRIBUTING guide. Under Option A, Docker builds, signs and publishes the image to `mcp/your-server-name` on Docker Hub and the catalog entry appears within 24 hours; Option B is a self-provided pre-built image used directly in the catalog. ### What is the difference between a Docker-built image and a self-provided one? A Docker-built image includes cryptographic signatures, provenance tracking, SBOMs and automatic security updates, and it is published to the `mcp` namespace. A self-provided image is used directly in the catalog and still benefits from container isolation, but does not include those enhanced security features. ### What must an MCP server do to comply with the Docker registry? It must follow security best practices, include comprehensive documentation, provide working Docker deployment, maintain compatibility with MCP standards, and include proper error handling and logging. Non-compliant servers are reviewed and may be removed from the registry. ## Sources - [docker/mcp-registry on GitHub](https://github.com/docker/mcp-registry) - [Issues](https://github.com/docker/mcp-registry/issues) - [License: MIT](https://github.com/docker/mcp-registry/blob/main/LICENSE) - [README](https://github.com/docker/mcp-registry/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/docker-mcp-registry