Docker MCP server setup for Claude Code and Cursor

Quick answer: The Docker MCP server is a Node process that talks to your local Docker daemon through the socket and exposes container and image operations as MCP tools. Install with one npx command, and Claude Code or Cursor can list containers, read logs, and run exec commands. Setup takes 3 minutes, tested on server version 0.7.0 against Docker Engine 25.0 on April 15, 2026.

The Docker MCP server makes your container world reachable from chat. Instead of a dozen docker ps and docker logs commands in a side terminal, the agent fetches the data, interprets it, and acts. That matters most during debugging - a crashing container is 2 tool calls away from an explanation.

This guide covers installation, editor config, working prompts, and the commands that intentionally require a confirmation flag.

What this server does

The server exposes about 20 Docker operations as MCP tools backed by the dockerode library. When Claude wants to list containers, it calls list_containers with optional status filters. When it wants to read logs, it calls get_container_logs with tail and follow options.

Main tool groups:

• Containers: list_containers, inspect_container, start_container, stop_container, restart_container, remove_container
• Logs and exec: get_container_logs, exec_in_container
• Images: list_images, inspect_image, pull_image, remove_image
• Networks: list_networks, inspect_network
• Volumes: list_volumes, inspect_volume
• System: docker_info, docker_version, docker_events (snapshot, not streaming)

The server connects to the Unix socket at /var/run/docker.sock on macOS and Linux, or the named pipe //./pipe/docker_engine on Windows. No credentials, no network traffic - the daemon authenticates via socket permissions.

Installing Docker MCP

The package is published as mcp-server-docker. The npx -y prefix fetches on first launch. Cold start is about 2 seconds and pulls roughly 2 MB.

You need Docker running locally:

1. On macOS, Docker Desktop handles the socket automatically.
2. On Linux, make sure your user is in the docker group (sudo usermod -aG docker $USER then log out and back in).
3. On Windows, use Docker Desktop with WSL2 integration enabled. The MCP server should run inside WSL, not Windows-native Node.

Verify with docker ps from the same shell where you will launch your editor. If that works, the MCP server will work.

For remote Docker daemons, set DOCKER_HOST in the env block to tcp://host:2375 or the TLS-secured form, and the server will use that instead of the socket.

Configuring for Claude Code

Claude Code reads MCP servers from ~/.claude/mcp.json globally or .mcp.json per project. Add a docker entry - no env vars required for local socket access:

{
  "mcpServers": {
    "docker": {
      "command": "npx",
      "args": ["-y", "mcp-server-docker"],
      "env": {}
    }
  }
}

Restart Claude Code. Run /mcp and you should see the server with around 20 tools. Call docker_version as a smoke test - if it returns your Docker Engine version, the wiring is correct.

For remote daemons, add "DOCKER_HOST": "tcp://10.0.0.5:2375" in the env block, and set DOCKER_TLS_VERIFY plus DOCKER_CERT_PATH if the endpoint uses TLS.

Configuring for Cursor

Cursor reads from ~/.cursor/mcp.json with the same JSON:

{
  "mcpServers": {
    "docker": {
      "command": "npx",
      "args": ["-y", "mcp-server-docker"],
      "env": {}
    }
  }
}

Open Cursor settings > MCP and toggle the server on. First tool call spawns the subprocess in about 2 seconds. Subsequent calls run 10 to 50 ms each against the local socket.

Example prompts and workflows

Once the server is attached, Docker is visible from chat. A few prompts:

• "List every running container and tell me which ones have been up more than 24 hours."
• "Read the last 200 log lines from the api container and summarize any error patterns."
• "Restart the redis container and wait for it to become healthy."
• "Run npm test inside the app container and show me the output."
• "Find images larger than 500 MB that are not used by any running container, then prune them with confirmation."

The model chains calls automatically. A debug loop usually runs list_containers to find the name, get_container_logs with tail: 200, and maybe inspect_container for env and ports. Three calls for a complete picture.

One pattern that saves time: use container names instead of IDs when possible. Claude remembers names across a conversation; IDs are opaque and churn on every recreation.

Troubleshooting

Connection fails with EACCES on /var/run/docker.sock. Your user is not in the docker group. Run sudo usermod -aG docker $USER, log out, log back in, and restart the editor.

Tool call fails with "no such container". The ID or name is wrong, or the container was removed between tool calls. Ask the agent to run list_containers first to confirm.

Exec inside container times out. The command ran longer than 60 seconds. For long-running commands, tell the agent to launch them in detached mode with nohup or spawn them as a separate container.

Logs endpoint returns nothing. The container uses a non-default logging driver. Check with docker inspect - if the driver is none or a remote driver, local log reads will not work.

Server fails with ENOENT. npx is not on PATH. Launch the editor from a shell session or hardcode the npx absolute path.

Alternatives

If the Docker server does not fit, a few options exist:

• podman-mcp for teams using Podman instead of Docker.
• docker-compose-mcp for workflows that mostly use compose files and want up, down, and logs tools scoped to services.
• kubernetes-mcp if you have graduated from local Docker to a cluster.

For CI debugging, a shell MCP with docker on PATH can run raw docker build, docker buildx, and docker compose commands the server does not expose. Trade-off is less safety - the agent could run any shell command.

The Docker MCP server is the right default for local dev loops. Three minutes of setup replaces hours of docker ps and docker logs in a side terminal. Keep it scoped to the local daemon until you trust the prompt patterns, then consider a remote setup for shared dev boxes.