Docker MCP Toolkit: Running MCP Servers in Containers

The MCP Toolkit is a part of Docker Desktop that runs MCP servers as containers instead of as programs on your machine. You pick servers from Docker’s MCP Catalog, group them into a profile, and connect your AI clients (Claude Code, Cursor, VS Code, Codex and others) to that profile once. Behind the scenes every client talks to the MCP Gateway, which starts the right container when a tool is called, gives it the credentials it needs, and applies limits: one CPU, 2 GB of memory and no access to your files unless you grant it. You configure a server once rather than once per client, and a local server no longer runs as you.

Three parts, three jobs

• The MCP Catalog is where servers come from. Docker’s catalogue documentation↗ (opens in a new tab) describes it as a curated collection of verified MCP servers packaged as images and distributed through Docker Hub. It lists local servers, which run as containers on your machine, and remote servers, which run on the provider’s side and often sign in with OAuth. Teams can also build their own catalogue to restrict which servers are approved.
• The MCP Toolkit is the management screen in Docker Desktop. It browses the catalogue, keeps your profiles, stores configuration and OAuth sign-ins, and connects clients.
• The MCP Gateway is the process your clients actually talk to. It is open source, runs as the docker mcp command-line plugin, and acts as a single proxy between clients and servers, managing configuration, credentials and access control.

Profiles tie them together. A profile is a named collection of servers with their configuration, say “frontend” with GitHub and Playwright, and “data” with a Postgres server, so a project’s client sees only the servers that project needs. The Toolkit documentation describes the Docker Desktop 4.62 interface and later; earlier versions have a different one, so older guides may not match your screen.

Turning it on

The Toolkit is a beta feature. Docker’s get-started guide↗ (opens in a new tab) gives the steps:

1. Update Docker Desktop to the latest version.
2. Open Settings, choose Beta features, select Enable Docker MCP Toolkit, then Apply.
3. In MCP Toolkit, open the Profiles tab and create a profile.
4. In the Catalog tab, choose a server and use Add to, picking your profile. A server marked Configuration Required needs its settings or sign-in before it works.
5. In the Clients tab, select Connect next to each client you use.

Without Docker Desktop, for example on a server with only Docker Engine, the gateway can be installed on its own as a Docker CLI plugin; the graphical Toolkit is a Docker Desktop feature.

The same from the command line

Everything the screens do is also a docker mcp command, documented in Use MCP Toolkit from the CLI↗ (opens in a new tab). Server references can be catalog://, docker://, https:// or file://.

# browse the catalogue and make a profile
docker mcp catalog server ls mcp/docker-mcp-catalog
docker mcp profile create --name frontend
docker mcp profile server add frontend --server <server-uri>
docker mcp profile show frontend

# connect clients to that profile
docker mcp client connect claude-code --profile frontend
docker mcp client connect cursor --profile frontend

# keep the profile in version control, without its credentials
docker mcp profile export frontend ./mcp-profile

docker mcp client connect knows about claude-code, claude-desktop, cline, codex, continue, cursor, gemini, goose, kiro, opencode, vscode and zed, among others. Check the result in the client itself: claude mcp list in Claude Code and codex mcp list in Codex should both show a server called MCP_DOCKER.

Connecting a client by hand

Any client that can start a stdio server can use the gateway, because a connection is just a command: docker mcp gateway run with your profile. In VS Code, docker mcp client connect vscode --profile frontend writes .vscode/mcp.json in the current folder, or you can add the entry to your user configuration yourself:

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

That entry is a local server with no sign-in, which also matters in VS Code: its agent harness guide↗ (opens in a new tab) says Copilot sessions can currently reach only local MCP servers that need no authentication, and the gateway is one. What the file can hold is covered in the VS Code mcp.json guide.

Secrets and OAuth

• API keys and passwords go in your operating system’s keychain, not in a config file. docker mcp secret set stores one, reading the value from standard input so it stays out of your shell history, and docker mcp secret ls lists them.
• Servers that sign in with OAuth, such as GitHub and Notion, are authorised in Docker Desktop: add the server, choose OAuth in its Configuration tab, and finish the sign-in in the browser. The OAuth tab lists every authorised service, with a Revoke button next to each.
• Removing a server does not remove its credentials. Docker’s FAQ says to delete them yourself with docker mcp secret rm.
• Shared profiles leave credentials out. Exporting or pushing a profile carries server choices and settings, and each person adds their own secrets.

cat pwd.txt | docker mcp secret set postgres_password

What the containers protect you from

The Toolkit’s security section↗ (opens in a new tab) lists two kinds of protection. Passive: images under mcp/ in the catalogue are built and signed by Docker. Active, at run time:

• Each server runs in its own container, limited to one CPU and 2 GB of memory.
• Servers have no access to the host filesystem unless you choose to give a server a file mount.
• Requests to and from tools that contain secrets are blocked.

The gateway command exposes the same controls as options. The gateway run reference↗ (opens in a new tab) shows --block-secrets and --log-calls on by default, --cpus 1 and --memory 2Gb per server, and adds --verify-signatures to check image signatures and --block-network to stop tools reaching forbidden network resources. --servers and --tools narrow what a client sees.

What containers do not fix: a server with your GitHub token can still do anything that token allows, and text a tool returns can still carry instructions aimed at the model. Docker’s own FAQ calls its catalogue checks a best-effort approach that is not yet exhaustive. Scope the credentials you give each server, keep approval prompts on in the client, and read MCP security risks for the attacks that isolation leaves open. Whether a gateway belongs in your set-up at all, and how it must handle tokens, is the subject of MCP gateway security.

Who it suits

• You run several local servers that need secrets or file access, and would rather they ran in a container than as you.
• You use more than one client and are tired of configuring the same servers in each.
• Your team wants an agreed set of servers per project, shared as a profile, with each person’s credentials kept on their own machine.

It adds less when every server you use is remote and signs each person in with OAuth: the provider already runs it, and the sign-in already scopes it. For centrally managed gateways across an organisation, Docker’s overview notes that the MCP Gateway as part of Docker AI Governance is invite-only.

A task board next to the containers

fenbs is one of those remote servers. It runs at https://fenbs.ai/api/mcp, and each person’s client signs in with OAuth and gets an hour-long token with refresh, capped by the scopes ticked at approval and by that person’s role on the board. A container adds nothing to that, so connect fenbs to the client directly, beside MCP_DOCKER, rather than into a profile. A client that only runs stdio servers can use the fenbs-mcp bridge instead, FENBS_TOKEN=… npx -y fenbs-mcp, with a token issued in Settings with a name, scopes and an optional expiry. Keep that token in your secret store like any other; if one token is shared, every change is recorded as the person who issued it.