CommunityAbandoned· 1.0y★ 4.3by ckreiling

Docker

Docker's official MCP — list containers, images, compose stacks; run targeted commands. Great for local-first AI dev workflows.

View repo Homepage

Safety & Trust

Delv Safety Grade: B

Score 72/100 · assessed 2026-04-28

Maintainer65

Permissions45

Supply chain75

Transparency85

Incidents100

Docker's official MCP server provides direct access to your local Docker daemon, enabling AI assistants to list containers, inspect images, query compose stacks, and execute Docker commands. Whilst Docker officially endorses this integration and it's distributed via uvx with reasonable transparency, the maintainer appears to be a solo community developer (ckreiling) rather than Docker Inc itself, creating some ambiguity around long-term support. The permissions footprint is substantial: it can execute arbitrary Docker commands, which effectively grants shell access to any running container and the ability to manipulate your entire container infrastructure. For local development workflows this is powerful and convenient, but it means Claude has broad control over your Docker environment. The supply chain is clean (standard Python package via uvx) and there are no known incidents. Best suited for developers who understand the Docker security model and are comfortable granting their AI assistant container-level access.

Lethal Trifecta (prompt-injection exposure)

ONE OF THREE

Private dataYes

Reads secrets, credentials, private files

Untrusted inputNo

Ingests web pages, PRs, issues, emails

External commsNo

Can send data outbound

Container control reads local file paths and config; doesn't talk out by itself.

Green flags

Endorsed by Docker in official blog post announcement
Open source with clear documentation and examples
Standard uvx distribution, no custom install scripts
No environment variables or secrets required
Active development with recent commits

Red flags

Can execute arbitrary Docker commands including container shell access
Maintainer is solo developer, not Docker Inc despite 'official' branding
No authentication or scoping mechanism for Docker daemon access
Could manipulate production containers if daemon has access

Permissions requested

Shell executeRead filesWrite filesOutbound networkRead env

Assessed by Delv Editorial using public metadata. Grades are advisory and update as the ecosystem changes. They do not replace your own review of permissions and code before granting an agent access to sensitive systems.

Install

uvx mcp-server-docker

Review

Docker's official MCP server gives Claude and friends direct access to your local Docker daemon. You can list running containers, inspect images, query compose stacks, and fire off targeted commands without leaving your AI chat. It's a first-party integration, which means it tracks Docker's API closely and doesn't feel bolted on. I reach for this when I'm debugging a containerised service and want Claude to help me trace logs, check environment variables, or spot misconfigurations. Instead of copying and pasting terminal output, I just ask Claude to list my containers or show me the logs for a specific service. It's particularly good for compose-heavy projects where you're juggling multiple services and want to sanity-check which versions are running or whether a restart fixed that networking issue. The server exposes a handful of tools: list containers, list images, list compose projects, and run arbitrary Docker commands. That last one is the escape hatch. If you need something beyond the built-in helpers, you can pass raw Docker CLI arguments and get structured output back. It's not a full Docker UI replacement, but it's not trying to be. It's a bridge for conversational workflows. Quirks: it assumes you've got Docker running locally and that your user has the right permissions. If you're on Linux and haven't added yourself to the docker group, you'll hit permission errors. The server doesn't manage Docker itself, it just talks to the daemon. Also, it's Python-based and installed via uvx, so you'll need a working Python environment. Not a dealbreaker, but worth noting if you're trying to keep your toolchain minimal. Who shouldn't bother: if you're working with remote Docker hosts or Kubernetes clusters, this won't help. It's strictly local. And if you're already comfortable with Docker CLI shortcuts and don't see the value in conversational access, you won't miss it. But for anyone building or debugging containerised apps with an AI assistant in the loop, it's a genuine time-saver.

Verdict

Install this if you're developing with Docker locally and want your AI assistant to help you troubleshoot without constant context-switching. Skip it if you're working with remote clusters or don't see the point of conversational container management. It's a narrow tool that does one thing well.

Good at

First-party integration from Docker, so it tracks the API reliably and feels native.
Conversational access to containers, images, and compose stacks without leaving your AI chat.
Escape hatch via raw Docker commands means you're not locked into a limited toolset.
Works across multiple MCP hosts, including Claude Desktop, Cursor, and Zed.
No environment variables or complex config required, just a working Docker daemon.

Watch out

Strictly local Docker only, no support for remote hosts or Kubernetes clusters.
Requires a Python environment and uvx, which adds a dependency if you're keeping tooling minimal.
Permission issues on Linux if your user isn't in the docker group can block usage.
Hosts beyond Claude Desktop may need manual config tweaks to wire it up correctly.

Getting started

1. Run `uvx mcp-server-docker` to install the server via uvx. Make sure Docker is running locally and your user has permission to access the Docker socket. 2. Add the server to your MCP host config (e.g. Claude Desktop's `claude_desktop_config.json`) under the `mcpServers` key. Point the command to `uvx` with `mcp-server-docker` as the argument. 3. Restart your host application and verify the connection by asking your assistant to list running Docker containers. You should see output if any containers are active. 4. Watch out for permission errors on Linux. If you see 'permission denied' when accessing `/var/run/docker.sock`, add your user to the docker group and log out and back in. 5. Try a real workflow: ask your assistant to show logs for a specific container by name, or to list all images and filter by a tag. This confirms the server is responding to targeted queries.

Works with

Claude DesktopClaude CodeCursorWindsurfClineZed