Nineteen tools. One Docker socket. And suddenly your AI agent can spin up containers, build images, manage networks, and handle volumes — all through natural language.
The Docker MCP server by Christian Kreiling is the most comprehensive community-built MCP server for Docker operations. With 687 stars and ~9,500 monthly PyPI downloads, it’s become the go-to choice for developers who want their AI agents to manage Docker environments directly. It’s not official from Docker, Inc. — but it’s the one people actually use for container management.
What It Does
The server exposes 19 tools across four Docker primitives:
Containers (8 tools):
| Tool | What it does |
|---|---|
list_containers |
List containers with ID, name, status, and image |
create_container |
Create a container from an image with ports, env, volumes |
run_container |
Create and start a container in one step |
recreate_container |
Recreate an existing container with updated settings |
start_container |
Start a stopped container |
fetch_container_logs |
Retrieve and tail container logs |
stop_container |
Stop a running container |
remove_container |
Remove a container from the host |
Images (5 tools):
| Tool | What it does |
|---|---|
list_images |
List available Docker images |
pull_image |
Pull an image from a registry |
push_image |
Push an image to a registry |
build_image |
Build an image from a Dockerfile |
remove_image |
Remove an image from the local daemon |
Networks (3 tools):
| Tool | What it does |
|---|---|
list_networks |
List Docker networks |
create_network |
Create a new network |
remove_network |
Remove a network |
Volumes (3 tools):
| Tool | What it does |
|---|---|
list_volumes |
List Docker volumes |
create_volume |
Create a new volume |
remove_volume |
Remove a volume |
Beyond tools, the server also provides resources — per-container stats (CPU, memory) and log tailing — and a docker_compose prompt that enables a plan-and-apply workflow where the LLM proposes container configurations for user review before execution.
Setup
Installation is clean. The recommended method uses uvx:
{
"mcpServers": {
"mcp-server-docker": {
"command": "uvx",
"args": ["mcp-server-docker"]
}
}
}
For running inside Docker itself (which has a nice meta quality):
{
"mcpServers": {
"mcp-server-docker": {
"command": "docker",
"args": ["run", "-i", "--rm",
"-v", "/var/run/docker.sock:/var/run/docker.sock",
"mcp-server-docker:latest"]
}
}
}
For remote Docker daemons, set the DOCKER_HOST environment variable to an SSH target:
{
"mcpServers": {
"mcp-server-docker": {
"command": "uvx",
"args": ["mcp-server-docker"],
"env": {
"DOCKER_HOST": "ssh://username@host.example.com"
}
}
}
}
Setup difficulty: Easy. No API keys. No cloud accounts. Just Docker running on the machine and a socket to connect to. The SSH remote option is genuinely useful for managing containers on development servers without leaving your IDE.
What Works Well
Full container lifecycle. Unlike simpler Docker MCP servers that only list and stop containers, this one covers create, run, recreate, start, stop, remove, and log tailing. An agent can go from “I need a Redis instance” to a running container in one conversation turn.
Image build support. The build_image tool means an agent can read a Dockerfile, build the image, and run a container from it — a complete development workflow. Most Docker MCP alternatives skip this entirely.
Remote Docker via SSH. Setting DOCKER_HOST to an SSH target lets agents manage containers on remote machines. This isn’t a toy feature — it’s how many teams manage their development and staging servers. The server uses the Python Docker SDK’s from_env() method and Paramiko for SSH transport, so it works with standard SSH key authentication.
The docker_compose prompt. This is a thoughtful design pattern. Instead of blindly executing Docker commands, the LLM first proposes a container configuration (essentially a docker-compose.yml equivalent) for the user to review. “Plan then apply” is how infrastructure tools like Terraform work, and it makes sense for Docker too. You see what the agent wants to create before it creates it.
Security-conscious defaults. The server explicitly blocks --privileged, --cap-add, and --cap-drop flags. This is a pragmatic choice — an AI agent with access to --privileged containers could compromise the host machine. The README also warns against including secrets in prompts and recommends reviewing LLM-generated configurations before execution.
Resources for observability. Per-container stats (CPU, memory, network) and log tailing as MCP resources means agents can monitor running containers, not just manage them. “Is my container using too much memory?” becomes a natural language question with a real answer.
What Doesn’t Work Well
No exec into running containers. Issue #22 requests the ability to run arbitrary commands inside running containers — a core Docker workflow. Without docker exec, agents can create and monitor containers but can’t interact with what’s running inside them. This is labeled as a “good first issue,” so it may come eventually.
No Docker Compose file support. Despite having a docker_compose prompt, the server doesn’t actually parse or deploy docker-compose.yml files. The prompt generates a plan that uses individual container tools, not Compose. If you have an existing docker-compose.yml, the agent can’t docker compose up it directly.
No secrets management. Issue #12, opened by the author himself, acknowledges the need for Docker secrets support. Currently, there’s no safe way to pass sensitive configuration to containers through the MCP server. The workaround — environment variables — is exactly what Docker secrets was designed to replace.
VS Code validation fails. Issue #46 and #25 report that the tool schema for create_container has an array type without an items property, causing validation errors in VS Code Copilot. A schema bug in one of the most important tools is a real friction point for VS Code users.
No volume or network remove operations with force. While the server can remove containers, the volume and network removal tools don’t offer force options. If a volume is in use or a network has connected containers, removal will fail without a clear path to resolve it.
stdio only. No HTTP or SSE transport. In an ecosystem where remote MCP servers are increasingly common, stdio limits this server to local machine usage (or SSH tunneling). You can’t run a shared Docker management endpoint that multiple team members connect to.
Slow release cadence. The latest release (v0.2.1) was June 2025. With 53 total commits and only 3 contributors, this is a small project. The 10 open issues — some open for nearly a year — suggest maintenance is sporadic. GPL-3.0 licensing may also deter some enterprise users and contributors.
How It Compares
The Docker MCP server space is fragmented — multiple small projects, no single dominant player, and no official server from Docker, Inc. (Docker’s MCP efforts focus on the MCP Toolkit and registry, not a container management server).
vs. QuantGeekDev/docker-mcp (454 stars): Simpler — only 4 tools (create container, deploy compose, get logs, list containers). But it directly supports docker-compose.yml deployment, which ckreiling’s doesn’t. Last updated December 2024 and appears abandoned. MIT licensed. Choose this only if you need simple Compose stack deployment.
vs. ofershap/mcp-server-docker (0 stars): TypeScript alternative with 10 tools. Includes exec_command (which ckreiling’s lacks) and container_stats. Newer (February 2026), less proven, but filling gaps. MIT licensed. Worth watching.
vs. Docker MCP Toolkit: Not a competitor — it’s a different thing entirely. Docker’s Toolkit is infrastructure for running MCP servers in containers, not an MCP server for Docker. The Toolkit includes a catalog of 300+ servers, a gateway, and OAuth management. ckreiling’s server could run inside the Toolkit.
vs. Kubernetes MCP servers: If you’re at the Kubernetes scale, you need Kubernetes-specific tools. Docker MCP servers target the docker/docker-compose layer — local development, simple deployments, CI/CD pipelines. Different audience.
The Bottom Line
The Docker MCP server is the most practical way to give AI agents Docker management capabilities today. Nineteen tools covering containers, images, networks, and volumes is a solid foundation. The SSH remote support, plan-and-apply prompt, and security defaults show thoughtful design.
But the gaps are real. No exec, no Compose file support, no secrets, and schema validation bugs in VS Code make this a “works well for basic workflows” server rather than a production-complete Docker management solution. The GPL-3.0 license and slow release cadence (3 contributors, 53 commits, last release June 2025) raise questions about long-term maintenance.
For the common use case — “agent, spin up a Postgres container for me” or “what’s running on this machine?” — it works well. For anything approaching production container orchestration, you’ll outgrow it quickly. The Docker ecosystem is waiting for either Docker, Inc. to ship an official container management MCP server, or for one of these community projects to break away from the pack.
Rating: 3.5 out of 5 — the most complete Docker MCP server available, with practical design and good security defaults, held back by missing exec/compose capabilities, maintenance concerns, and stdio-only transport.
| MCP Server | Docker MCP Server |
| Publisher | ckreiling (community) |
| Repository | ckreiling/mcp-server-docker |
| Stars | ~687 |
| Tools | 19 (+ resources and prompts) |
| Transport | stdio |
| Language | Python |
| License | GPL-3.0 |
| Pricing | Free |
| Our rating | 3.5/5 |