Docker shipped a set of tools that let a platform team decide exactly which Model Context Protocol servers developers can run: a catalog format, an open-source Gateway, and a Toolkit built into Docker Desktop. The official catalog carries 220+ containerized MCP servers, and you can fork it, trim it, or build a private catalog that points at images in your own registry.
The catalog and the GUI are the convenient part. The Gateway is the part that changes how you govern MCP at any real scale.
Wire N servers into M developer tools directly and you own N×M config entries, each with its own secrets and its own blast radius. The Gateway collapses that to one connection per client. Servers run as ordinary containers with restricted privileges and network access; the Gateway manages their lifecycle, injects credentials from a secret store, and logs every tool call.
That last point is the enterprise payoff: a single, auditable choke point for what your agents can reach, instead of API keys scattered across a dozen mcp.json files on developer laptops.
What I would actually do with it: if you already run a private registry and block direct Docker Hub pulls, fork the catalog, retag the servers you trust into your registry, and hand teams the Gateway config. The call-tracing alone earns its keep the first time someone in a security review asks which tool touched a given system.
Two gaps to watch. The catalog is Docker-curated, so a server your team needs may not be there yet, and you rebuild it from source when it is not. And routing every developer’s MCP traffic through one Gateway makes it a component you now have to scale, monitor, and keep available.
Learn more: Docker’s step-by-step tutorial, the MCP Catalog and Toolkit docs, and the MCP Gateway repo.