What Docker MCP Gateway is and what this review covers
Docker MCP Gateway is the routing and lifecycle layer behind Docker’s MCP Toolkit. Instead of wiring every AI client directly to every MCP server, a profile selects the servers and tools that a client can reach, while the gateway handles discovery, container startup, credential mediation, routing, and shutdown. The open-source gateway and docker mcp CLI are distinct from Docker AI Governance’s invite-only gateway capability. That distinction matters: the local developer product is useful today, but it should not be presented as a complete enterprise RBAC or audit platform simply because both offerings use the gateway name.
This review is based on Docker's MCP Gateway and MCP Toolkit documentation, the docker/mcp-gateway repository, and its release notes. It describes documented behavior and does not include an aicoolies test record.
Setup, tool exposure, and server lifecycle
The documented CLI path is to create a named profile with catalog references, inspect it, and launch tools through `docker mcp gateway run` or the `docker mcp tools` helpers. Catalog servers are referenced by digest-pinned images, and a tool listing shows the servers' tools alongside the gateway's own management tools. That makes the profile boundary visible before an agent is connected.
According to Docker's documentation, the gateway verifies signatures on Docker's own `mcp/` images by default, starts a server's container on demand when a tool is first needed, and by default does not keep containers long-lived (a `--long-lived` flag keeps them until the gateway stops). Docker documents restrictive defaults for server containers: 1 CPU, 2 GB of memory, and no-new-privileges.
Permission boundaries: useful controls, not a complete policy layer
The most concrete documented control is per-profile tool configuration. Docker documents that individual tools can be disabled without removing their server, so a team can remove a dangerous operation while keeping the rest of a server, and separate profiles can give coding, research, and production agents different tool surfaces.
Container defaults add another layer, but they are not business authorization. Docker's documentation says server containers get no host filesystem access by default and that secret blocking (`--block-secrets`) is on by default. It also states that network egress is not globally denied by default, so teams should check network flags against the exact destinations they care about, including Docker Desktop host routes such as host.docker.internal. Buyers should test the destinations, mounts, secrets, and transports they intend to allow, then add external network controls and identity policy where the threat model requires them.
Logs and troubleshooting
The gateway has a `--verbose` mode and call logging that is on by default; Docker says call logs record tool names and argument shape, not raw argument values. Individual servers can also emit their own warnings, so teams should read server-level messages instead of treating a healthy gateway status as proof that every server runs in its preferred mode.
Pricing, maturity, and operational fit
The docker/mcp-gateway repository is MIT-licensed and actively maintained, with v0.44.1 pushed on 23 Sep 2026. Its published releases are marked prerelease, and Docker labels MCP Catalog and Toolkit as beta. The right reading is "usable and actively developed, but still moving," not a mature, frozen control plane. Docker Desktop licensing and the invite-only AI Governance product remain separate commercial considerations.
Operationally, Docker MCP Gateway is strongest for developers and platform teams already standardized on Docker Desktop or Docker Engine. It replaces per-client server wiring with reusable catalogs and profiles, verifies catalog images, centralizes secret handling, and gives one troubleshooting surface. The tradeoff is weight: Docker must be healthy, images must be available, catalog and profile state must be maintained, and gateway initialization and container startup add latency before the first tool call. Direct stdio servers can be simpler for one trusted local tool, while a dedicated enterprise gateway may be better when centralized identity, organization-wide policy, retention, and formal audit controls are mandatory.
Verdict and alternatives
Docker MCP Gateway earns a strong recommendation for local and team development environments that want repeatable MCP packaging without running arbitrary npm or Python processes directly on the host. The combination of digest-pinned catalog images, signature verification, constrained containers, profiles, tool allowlists, secret scanning, and verbose mode and call logging is materially better than an unmanaged collection of client-specific commands. The documented path from an empty catalog to a narrow, allowlisted profile is short. Existing Docker users gain the most because the runtime and operational habits are already present.
It is not the final answer for every governance problem. Use ToolHive when a Kubernetes-oriented, policy-forward deployment model is the priority; consider IBM’s MCP Context Forge when centralized federation and enterprise gateway controls matter more than Docker Desktop integration; use Smithery or a registry-style service when discovery and hosted distribution are the main need rather than local container orchestration. For Docker-centric teams, start with a narrow profile, explicitly allow only required tools, verify mounts and network behavior against real destinations, and retain verbose call logs during rollout. Adopt it for orchestration and containment, then layer identity and network policy around it instead of assuming isolation equals authorization.
