What Docker MCP Gateway is and what we tested
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.
Our hands-on run used an Apple-silicon Mac with Docker Desktop 4.81.0, Docker Engine and CLI 29.6.1, and Docker MCP Toolkit CLI v0.43.1. We pulled Docker’s official MCP Catalog at digest efc2e0f2caca8690086139de11a4b777944d1e37678521f71e5549a9b970a37f, then created a dedicated profile containing the Fetch and Sequential Thinking reference servers. The catalog exposed 314 server definitions in this snapshot. This was a real local run on August 13, 2026, not a docs-only walkthrough, and the temporary profile was isolated from the user’s existing client configurations.
Hands-on setup, tool exposure, and server lifecycle
The CLI path was straightforward once the catalog existed: create a named profile with catalog:// references, inspect it, and launch tools through docker mcp gateway run or the docker mcp tools helpers. The profile resolved both servers to digest-pinned images: mcp/fetch@sha256:1a7a0996a565a0b8ca5c41b42830d4e5f334d33f851596bbd9debb2beedb22d3 and mcp/sequentialthinking@sha256:cd3174b2ecf37738654cf7671fb1b719a225c40a78274817da00c4241f465e5f. A tool listing exposed fetch and sequentialthinking alongside the gateway’s dynamic management tools. That made the profile boundary visible before an agent was connected and avoided guessing which tools a client would receive.
Lifecycle behavior matched the gateway design. Verbose output showed image verification, image pull or cache resolution, MCP initialize negotiation using protocol version 2025-06-18, tool enumeration, on-demand container launch, the tool call, and container release when the CLI client disconnected. Server containers ran with --rm, --init, no-new-privileges, a one-CPU limit, a 2 GB memory limit, and --pull never after verification. Fetching Docker’s own MCP documentation succeeded through the exposed Fetch tool in 1.68 seconds on the first measured call. No docker-mcp-labeled server container remained after the client session ended, which is the clean ephemeral lifecycle we wanted to see.
Permission boundaries: useful controls, not a complete policy layer
The strongest permission control we verified was the profile tool allowlist. Disabling fetch.fetch changed the stored profile entry to tools: [], removed Fetch from the external tool list, and caused a direct call to fail with “unknown tool fetch.” Re-enabling that exact tool restored exposure and the next documentation fetch completed successfully in 2.26 seconds. This is a concrete, testable least-privilege boundary: teams can remove a dangerous operation without removing its whole server, and the failure is explicit rather than silently routed somewhere else. Separate profiles can therefore give coding, research, and production agents different tool surfaces.
Container defaults add another layer, but they should not be confused with business authorization. Our logs confirmed no-new-privileges plus CPU and memory limits, and Docker’s current documentation says host filesystem mounts require explicit configuration and secret-shaped request or response data is intercepted. However, a paired network test reached a host.docker.internal service both with and without --block-network. The flag did not behave as a universal deny-all switch for that Docker Desktop host route in this setup. Buyers should test the exact destinations, mounts, secrets, and transports they intend to allow, then add external network controls and identity policy where the threat model requires them.
Logs, failures, and recovery in practice
Verbose logs were detailed enough to explain most failures without opening Docker Desktop’s UI. They identified the profile, catalog size, verified images, enabled servers, container flags, exposed tool counts, protocol initialization, secret scans, call duration, response scan, and client disconnect. The Fetch server also emitted a useful warning that Node was absent and it had fallen back to pure-Python extraction mode. That warning did not break the request, but it shows why teams should inspect server-level messages rather than treating a successful gateway status as proof that every server is running in its preferred mode.
We exercised two recovery paths. First, passing the Sequential Thinking CLI a single JSON blob produced a schema error because docker mcp tools call expects key=value arguments; the gateway released the containers and a later correctly shaped Fetch call worked normally. Second, the intentional allowlist denial returned an unknown-tool error, after which re-enabling fetch.fetch restored both listing and execution without rebuilding the profile or restarting Docker Desktop. Shutdown logs included a canceled localhost OAuth notification connection after the CLI client exited. In this context it was cleanup noise, not a failed tool call, but production log pipelines should distinguish expected disconnect messages from server crashes.
Pricing, maturity, and operational fit
The docker/mcp-gateway repository is MIT-licensed, public, active, and not archived. At this review’s refresh it had 1,526 GitHub stars, a verified main-branch commit from August 11, 2026, and continuing security-policy work. The local install reported v0.43.1 while GitHub listed v0.43.3 as the newest published prerelease; all visible releases were marked prerelease, and Docker labels MCP Catalog and Toolkit as beta. The correct purchasing interpretation is therefore “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 a gateway initialization added roughly 2.4 to 2.8 seconds before our measured tool calls in warm runs. 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 readable lifecycle logs is materially better than an unmanaged collection of client-specific commands. The hands-on path from empty catalog to two exposed tools was clear, and both the intentional failure and permission-denial scenarios recovered cleanly. 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.