Docker MCP Gateway and Toolkit: Setup, Catalog and Security (Oct 2026)

On this page

Docker MCP is three pieces: the open-source MCP Gateway that runs servers in containers, the MCP Toolkit UI in Docker Desktop that drives it, and the MCP Catalog of containerized servers. TrustedMCP grades the Gateway B. The servers you run through it each need their own review.

How the three pieces fit

MCP Gateway. Docker's docs call it "Docker's open source solution for orchestrating Model Context Protocol (MCP) servers." It's the docker mcp CLI plugin from the docker/mcp-gateway repo. Your AI client connects to the Gateway as one MCP server, and the Gateway starts the real servers in containers and routes each tool call to the right one.

MCP Toolkit. The Toolkit docs describe it as "a management interface integrated into Docker Desktop." You pick servers, set their config and secrets, and connect clients with buttons. Under the hood it uses the Gateway. The docs say that with the Toolkit enabled, "the Gateway runs automatically in the background."

MCP Catalog. The catalog docs describe "a curated collection of verified MCP servers, packaged as Docker images and distributed through Docker Hub." You can browse it at hub.docker.com/mcp or in the Toolkit's Catalog tab.

Profiles tie it together. A profile is a named set of servers with their config. You connect a client to a profile, and the client sees only those servers' tools.

Setup

Docker Desktop (Toolkit). Docker's Toolkit docs cover Docker Desktop 4.62 and later. Open MCP Toolkit from the Docker Desktop menu, add servers from the Catalog tab to a profile, then open the Clients tab and select Connect next to your client.

Claude Code (from the mcp-gateway README):

docker mcp profile create --name dev-tools \
  --server catalog://mcp/docker-mcp-catalog/github
docker mcp client connect claude-code --profile dev-tools --global

The README says to run docker mcp catalog pull mcp/docker-mcp-catalog first.

Cursor: add --connect cursor to the profile create command above, or use the general form docker mcp client connect <client-name> --profile <profile-id>.

Claude Desktop: in the Toolkit's Clients tab, select Connect next to Claude Desktop, then restart Claude Desktop if it's running.

VS Code (one project):

docker mcp client connect vscode --profile my_profile
echo ".vscode/mcp.json" >> .gitignore

VS Code (global): the Toolkit docs add an MCP_DOCKER server to your user mcp.json that runs the Gateway over stdio:

"mcp": {
 "servers": {
   "MCP_DOCKER": {
     "command": "docker",
     "args": [
       "mcp",
       "gateway",
       "run",
       "--profile",
       "my_profile"
     ],
     "type": "stdio"
   }
 }
}

Without Docker Desktop: download the docker-mcp binary from the repo's releases into ~/.docker/cli-plugins/ and run docker mcp --help to check it. The README also says to set DOCKER_MCP_IN_CONTAINER=1 for WSL2, containers or Docker CE, and to run docker mcp feature enable profiles before using profiles.

What the containers isolate

Docker documents these protections in the Toolkit docs and the Gateway's security notes:

One container per server, started with no-new-privileges and resource limits. The defaults are 1 CPU and 2 GB of memory per server (--cpus and --memory).
No host filesystem by default. You grant mounts per server. Host paths are mounted read-only unless you explicitly allow a writable path.
Per-server secrets. The Gateway passes a server only the environment variables, config and secrets declared for that server. Your host environment isn't passed through. Secrets live in Docker Desktop's secret store (docker mcp secret), not in your client config. For the general pattern, see keeping API keys out of your MCP config.
Secret blocking. --block-secrets is on by default and scans tool-call arguments and responses for secret-like values.
Signed images. --verify-signatures is on by default for Docker's mcp/ images on Docker Hub. The catalog docs say Docker builds and signs its local servers and ships each with provenance and SBOM metadata.
Call logging. --log-calls is on by default and records the tool name and argument shape, not full values.
Interceptors. --interceptor runs your own hooks around tool calls, in the form when:type:path (for example before:exec:/bin/path).

What they don't isolate

Network egress is open by default. Docker's security notes say egress "is not globally denied by default." Add --block-network, or use per-server disableNetwork and allowHosts settings.
Granted access is still access. A server with your GitHub token can do whatever that token allows. The container stops it reading your disk. It doesn't stop it misusing the token.
Prompt injection passes straight through. Docker's notes put poisoned tool output out of scope unless it breaks a Gateway boundary. Text from an issue or web page reaches your model the same way it would without Docker.
HTTP mode needs care. The sse and streaming transports require a bearer token by default, but --allow-unauthenticated turns that off. Keep the Gateway on stdio, or bind it to localhost.

Review each server, not just the Gateway

Running a server in a container doesn't make the server trustworthy. Every catalog entry is a different codebase from a different publisher, with its own auth model, its own write tools and its own bugs. The container limits the damage, but you still decide whether to give that server your credentials.

So check each server before you add it to a profile. Use the 5-minute safety check and look the server up in the directory. Enable only the tools you need. The Gateway supports per-profile tool lists, for example docker mcp profile tools <profile-id> --enable github.create_issue. Fewer tools also means less context spent on tool definitions, as covered in how much context MCP tools cost. And don't rely on a server's read-only labels alone; see MCP tool annotations explained.

Why it grades B

The Gateway is first-party, open source and actively maintained, and its defaults are good: per-server secrets, signature checks, secret blocking and no host filesystem. That puts it well above running the same servers directly with npx.

It loses ground in three places. Network egress is open unless you turn on --block-network. The HTTP transports rely on one shared bearer token, which can be switched off. And its advisory history is long for a young project: ten published advisories, two rated critical, including one where image signature verification was off by default. Run a current release.

The grade is about the Gateway only. It says nothing about the servers you run through it. Details are on the Docker MCP Gateway listing.

Frequently asked questions

What's the difference between the Gateway and the Toolkit?

The Gateway is the engine: an open-source CLI plugin that runs servers in containers and gives your client one endpoint. The Toolkit is the Docker Desktop UI for managing it. You can use the Gateway alone from the command line. The Toolkit always uses the Gateway.

What's in the Docker MCP catalog?

Docker's docs say "300+" servers. Local servers run as containers on your machine and are built and signed by Docker. Remote servers run on the provider's infrastructure, from partners such as Stripe, Grafana and New Relic. Others can submit servers through Docker's registry. You can also build custom catalogs for your team.

Is the Docker MCP Toolkit deprecated?

Docker's docs don't describe it as deprecated or renamed as of Oct 2026. The current Toolkit docs cover Docker Desktop 4.62 and later and note that earlier versions have a different UI, which may be why older tutorials look out of date. The docs present the Toolkit, Gateway and Catalog as current, actively documented features.

Does it need Docker Desktop?

The Toolkit does. The Gateway doesn't: Docker documents installing the docker-mcp plugin on Docker Engine without Docker Desktop. Docker Desktop does give you its secret store and the Clients tab, so CLI-only setups take more configuration.

More: MCP security best practices · Is this MCP server safe to install?