Turkey (Turkish)
Germany (German)
Worldwide (English)
Docker MCP Toolkit is integrated into Docker Desktop to manage containerized MCP servers in profiles and connect them to AI clients.
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
Set up Docker MCP Toolkit, Catalog, Profiles, Gateway, Dynamic MCP, Claude/Cursor integration, credential isolation and the Docker Desktop 4.62+ CLI workflow.
Docker MCP Toolkit is integrated into Docker Desktop to manage containerized MCP servers in profiles and connect them to AI clients.
Docker's get-started guide describes the current interface for Docker Desktop 4.62 and later; earlier versions use a different UI.
MCP Gateway acts as a centralized proxy/orchestration layer between clients and MCP servers, handling lifecycle, routing, authentication and credentials.
Docker's MCP Catalog provides hundreds of verified servers as container images with versioning, provenance and SBOM metadata.
Traditional MCP setup often requires server commands, runtimes, environment variables and credentials in each client config. With many servers and several AI clients, dependency and secret management becomes fragmented. Docker standardizes servers as container images and connects clients through profiles.
Claude, Cursor and other MCP clients can then access the same approved tool set through a profile/gateway, reducing per-client Node/Python dependency setup.
Docker's current get-started guide targets the 4.62+ interface. Enable MCP Toolkit from Docker Desktop Beta features; earlier releases may have different menus.
On the CLI, Docker documents `docker mcp` commands in 4.62+ for profiles, servers, OAuth credentials and catalogs. If the command is missing, verify Docker Desktop version first.
docker versiondocker mcp --helpDocker MCP Catalog distributes servers as images instead of relying on ad-hoc dependency installation. Docker documents versioning, provenance and SBOM metadata for verified servers, improving supply-chain visibility compared with blindly executing arbitrary packages.
A verified label does not mean a tool should receive unlimited permissions. Design least-privilege access for filesystem, network, APIs and credentials.
Profiles centralize which MCP servers are exposed to clients for a project. For example, a development profile can include GitHub and database tools while support and marketing profiles expose different approved servers.
Profiles are also a security boundary for tool exposure. Instead of giving every agent all company tools, expose the minimum server set required for the task.
The Gateway receives a tool call, identifies the responsible server, starts its container if needed, injects credentials, applies restrictions and returns the result. Clients do not need to manage each server process directly.
With MCP Toolkit enabled in Docker Desktop, the Gateway runs automatically in the background. For Docker Engine/headless environments, the gateway CLI plugin can be installed separately and run with selected profiles.
docker mcp --helpToolkit is designed to work with Claude, Cursor and other MCP clients. The idea is to connect the client to the Gateway/profile rather than manually defining dozens of server commands. Use Docker Desktop's current Connect clients flow because client integration details can change by version.
After connecting, start with a read-only or low-risk tool call and verify the selected profile/server through Gateway logs or traces. Do not use destructive GitHub/database actions as the first test.
Docker Dynamic MCP gives agents gateway meta-tools to search the catalog and add MCP servers on demand, reducing the need to preconfigure every server before a session.
The feature is documented as experimental and materially changes the security model because an agent can expand its tool surface. Production environments may prefer tightly controlled profiles over unrestricted dynamic discovery.
The Gateway can inject credentials on demand and isolate servers in containers, which is cleaner than copying .env files. But tool permissions still affect real external systems. Container isolation does not remove destructive permissions from a GitHub token.
Design credential scopes, OAuth permissions, filesystem mounts, network egress and approval requirements separately. 'It runs in a Docker container' is not a complete security review.
For one or two simple local MCP servers and a single client, classic configuration can be simpler. Toolkit/Gateway becomes more attractive with multiple clients, many tools, credentials, versioning and team standardization.
On VPS/headless servers without Docker Desktop, use the manual gateway/CLI approach. If clients are remote, design network exposure and authentication explicitly; exposing a gateway port directly to the internet is not automatically safe.
| Scenario | Approach |
|---|---|
| 1 client + 1–2 local servers | Classic MCP config may be enough |
| Many clients + many servers | Toolkit + Profiles + Gateway |
| Agent discovers tools at runtime | Dynamic MCP with controlled policy |
| Headless Docker Engine VPS | Manual MCP Gateway / CLI |
Before production changes, verify context and keep backups and a rollback plan. Do not change several DNS, TLS, recovery, Docker or WordPress variables at once because it obscures the root cause.
Yes, the Toolkit is documented as integrated into Docker Desktop; exact feature/plan availability can evolve, so check current Docker docs.
With Toolkit enabled in Docker Desktop, the Gateway runs automatically; Docker Engine/headless advanced use can require the separate CLI plugin.
It is powerful but allows agents to expand their tool surface at runtime. Production use requires careful catalog, profile, credential and approval boundaries.
If the problem persists in hosting, VPS, Docker, Cloudflare, Windows or WordPress infrastructure, open a technical support request with the exact error output and current architecture.