Docker is a Cloud Platforms MCP server that lets Claude Code, Cursor, Windsurf and any MCP-compatible AI agent container management and Docker operations. Install in 1 minute with mcpizy install docker.
Cloud Platforms
Container management and Docker operations
Official homepagemcpizy install dockernpx -y @docker/mcp-serverlist_containersList running containers
Inputs
allbooleanoptionalstart_containerStart a stopped container
Inputs
container_idstringrequiredstop_containerStop a running container
Inputs
container_idstringrequiredget_logsFetch logs from a container
Inputs
container_idstringrequiredtailnumberoptionallist_imagesList local Docker images
pull_imagePull an image from a registry
Inputs
imagestringrequiredexec_commandRun a command inside a container
Inputs
container_idstringrequiredcommandstring[]requiredWorks identically across clients. Only the config file path differs.
~/.claude.json{
"mcpServers": {
"docker": {
"command": "uvx",
"args": [
"docker-mcp"
]
}
}
}.cursor/mcp.json{
"mcpServers": {
"docker": {
"command": "uvx",
"args": [
"docker-mcp"
]
}
}
}~/.codeium/windsurf/mcp_config.json{
"mcpServers": {
"docker": {
"command": "uvx",
"args": [
"docker-mcp"
]
}
}
}Make sure Docker Desktop is installed and the daemon is running
Paste any of these prompts into Claude Code, Cursor or another MCP-compatible client.
“List every running container and its image”
Uses: list_containers
“Show me the last 100 log lines from my `postgres` container”
Uses: list_containers, get_logs
“Pull the latest `redis:7-alpine` image”
Uses: pull_image
“Stop the container named `old-api`”
Uses: list_containers, stop_container
Docker MCP exposes the Docker Engine API as agent tools: `list_containers`, `run_container`, `stop_container`, `logs`, `exec`, `list_images`, `pull_image`, `build_image`. The MCP connects to the local Docker socket (`/var/run/docker.sock`) or a remote Docker daemon over TCP. Authentication is whatever the daemon enforces — typically socket permissions for local, TLS for remote.
We use Docker MCP for three workflows. First, dev-environment debugging: "is the Postgres container actually running" — `list_containers` + `logs` answer faster than `docker ps` + `docker logs` typed by hand. Second, build diagnosis: `build_image` with a streaming-log return surfaces the failing step. Third, exec-into-container for one-off commands: `exec` is the agent equivalent of `docker exec -it`. Token cost varies widely; container logs can be huge — pin a `tail` parameter (e.g. last 100 lines, ~3k tokens) rather than streaming everything.
Compared to Kubernetes MCP, Docker MCP is for local / single-host workflows; Kubernetes is for cluster-scale. Compared to Bash MCP + docker CLI, Docker MCP wins on structured output (container objects, log streams) and on safety (no shell injection). Honest trade-off: Docker socket access is effectively root on the host — any agent with Docker MCP can mount the host filesystem into a privileged container and escape. Treat Docker MCP as the highest-blast-radius MCP and gate it behind explicit human confirmation for write operations.
Docker socket = root on host. An agent with `run_container` can launch a privileged container that mounts `/` and reads/writes anywhere. There's no in-MCP sandbox. Run the agent in a VM or scoped CI environment for destructive ops.
`logs` with no `tail` defaults to the entire history. For long-running containers, this can be hundreds of MB. Always pass an explicit tail or time-range parameter.
`exec` runs a command inside an existing container — its safety depends on the container's user. If the container runs as root (most do), `exec` is root in that container. Treat with care.
Image pulls (`pull_image`) can be slow (hundreds of MB) and the MCP often blocks until done. Agent timeouts can fire mid-pull, leaving the agent confused. Pre-pull images out-of-band when possible.
Honest pros/cons against the closest cloud platforms MCP servers.
| Server | Strengths | Trade-offs |
|---|---|---|
| Kubernetes MCP | Right pick for cluster-scale workloads, declarative | Overkill for single-host dev, more concepts |
| Podman MCP (community) | Daemonless, rootless by default, safer | Smaller ecosystem, MCP coverage thinner |
| Bash MCP + docker CLI | Full surface, every command available | Shell injection, no structured output |
If Docker doesn't fit your stack, these Cloud Platforms MCP servers solve similar problems.
The Docker MCP server is an Cloud Platforms Model Context Protocol server that lets Claude Code, Cursor, Windsurf, VS Code with Copilot, and other MCP-compatible AI agents container management and Docker operations. It exposes Docker's capabilities as tools the AI can call directly from your editor or CLI.
The fastest way is the MCPizy CLI: run `mcpizy install docker` and MCPizy will add the server to your `.claude.json` automatically. You can also install it manually by adding an entry under `mcpServers` in `.claude.json` with the command `npx -y @docker/mcp-server` and restarting Claude Code.
Yes. The Docker MCP server is free and open source (see the GitHub repository linked on this page). You may still need a Docker account or API key to connect the server to the underlying service, but the MCP layer itself has no MCPizy subscription cost.
Yes. Any MCP-compatible client works — including Claude Code, Claude Desktop, Cursor (via `.cursor/mcp.json`), Windsurf, VS Code with Copilot Chat, and custom agents built on the MCP SDK. The same install command targets all of them; only the config file path differs.
Once installed, your AI agent can container management and Docker operations directly inside your conversation. Typical use cases include asking Claude Code or Cursor to run Docker operations, inspect results, chain Docker with other MCP servers (see our Workflow Recipes), and automate repetitive cloud platforms tasks without leaving your editor.