docker-mcp
This server lets an AI agent inspect and manage Docker and run self-checking practice labs, with read/lab/full modes and confirmation for dangerous actions.
Inspect server status, Docker requirements, Docker info, disk usage, containers, images, volumes, networks, and Compose services.
Manage containers: run, start, stop, restart, remove, exec commands, copy files, view logs, stats, and processes.
Manage images: list, inspect, pull, build, tag, push, and remove.
Manage volumes and networks: list, inspect, create, and remove.
Manage Compose projects: ps, logs, build, up, down, and exec.
Clean up unused Docker resources with prune.
Run labs: list, status, logs, up, exec, check, reset, and down under a lab safety policy.
In read mode it only reads; in lab mode it only runs labs; in full mode it can do everything Docker does, asking before dangerous/destructive actions.
Provides tools for interacting with Docker, enabling management of containers, images, volumes, networks, Compose projects, system information, cleanup, and self-checking practice labs, with configurable read-only, lab-only, or full access modes and safety confirmations for destructive operations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@docker-mcp Start a PostgreSQL 17 with a volume for its data, on port 5432 only for this computer."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
docker-mcp
Your AI agent works Docker for you: containers, images, Compose and practice labs. A complete set of tools, with modes chosen at startup: only read, only safe labs, or everything.
📖 Documentation · 📖 Documentación en español
docker-mcp is an MCP server that lets an AI agent (Claude Code, Codex, an agent built on agent-kit) work the Docker on your computer: run and inspect containers, build and pull images, manage volumes and networks, start Compose projects, clean up, and run practice labs that check themselves. You choose how far it can go when it starts: read only looks, lab only runs labs under a safety policy, and full does everything Docker does, asking before anything dangerous. It drives Docker's own command line, so it works wherever Docker does.
✨ Why docker-mcp
🎚️ Modes, not trust. A tool outside the mode doesn't exist for the agent: in
readit can't change anything, inlabit can't run anything but labs.🛡️ You confirm, not the agent. Before removing anything, and before a privileged container, the host's network or the Docker socket, docker-mcp asks you itself through your app, and your answer never passes through the model.
🧪 Labs for practices. A folder with a
compose.yamland a check: no internet, no host mounts, limits on CPU and memory, refused if it breaks the rules, reset in one call.🧰 The whole of Docker. 47 tools over containers, images, volumes, networks, Compose and the system, each with structured results.
🔧 Explains, never installs. Without Docker, or with it stopped, it says how to install or start it.
📦 Nothing to install. One bundled file run with
npx, for agent-kit, Claude Code and Codex alike.
Related MCP server: Docker MCP Server
🚀 Quick start
You need Node.js 20 or later and Docker 24 or later, running.
# Claude Code (full mode)
claude mcp add docker -- npx -y @falkenslab/docker-mcp
# Only labs, with the practices in a folder of your own
claude mcp add docker -e DOCKER_MCP_MODE=lab -e DOCKER_MCP_LABS_DIR=/path/to/labs -- npx -y @falkenslab/docker-mcpIn Codex, codex mcp add docker -- npx -y @falkenslab/docker-mcp. To write it in .mcp.json or Codex's config.toml, with every setting, see Configuration. In an agent built on agent-kit, or with its skills in Claude Code and Codex, install the docker-lab extension from agent-extensions, which runs this server at a fixed version. Then ask: "What containers are running?"
💬 What you can ask
🧑💻 "Start a PostgreSQL 17 with a volume for its data, on port 5432 only for this computer."
🧑💻 "Why does my web container keep restarting? Look at its logs."
🧑💻 "How much disk is Docker using, and what could I clean up?"
👩🏫 "Start the volumes lab and check the solution works."
🧑🎓 "Reset my lab: I broke the database."
📸 See it at work
🧰 What's inside
Area | Tools |
📦 Containers |
|
🖼️ Images |
|
💾 Volumes and networks |
|
🧩 Compose |
|
⚙️ System |
|
🧪 Labs |
|
🔌 Server |
|
Every tool, with what each mode keeps: the tools reference.
📚 Documentation
Getting started: installing it in your AI app.
Configuration:
.mcp.jsonfor Claude Code andconfig.tomlfor Codex, or their command lines, with every setting.Modes and settings:
read,labandfull, the areas, and the labs' policy.Tools: every tool, generated from the server.
🛠️ Developing
npm install, then npm run build, npm test and npm run check before every commit; CLAUDE.md lists every command and .minispec/ the decisions behind them (the modes are ADR-005, the labs' policy ADR-006). Releases are published to npm by the owner.
Made with 💖 by Falken's Lab Team
Available Tools
47 toolsbuild_imageBuild an imageA
Build an image from a local folder with a Dockerfile, and tag it. Returns the build's output (its end when long). Uses the network and disk: confirm with the person first.
Inputs: tag (required), context (required), noCache, buildArgs, +1 more. Returns: tag, output, exitCode, truncated
check_requirementsCheck the programs this server needsARead-only
Check the programs this server needs installed apart on the person's computer: whether each is there, its version, and, when one is missing or too old, how to install it on this system. Never installs anything: tell the person what to do.
Inputs: no named parameters. Returns: ok, requirements
compose_buildBuild a Compose projectA
Build the images of a Compose project's services that have a build (all, or some), without starting anything: to check a Dockerfile change, or to have the images ready. Returns the exit code and the build's output (its end when long); a failed build says why at the end. Uses the network and disk: confirm with the person first.
Inputs: folder (required), file, pull, noCache, +1 more. Returns: output, exitCode, truncated
compose_downStop a Compose projectADestructiveIdempotent
Stop and remove a Compose project's containers and networks; with volumes, its volumes and their data too. Confirm with the person first; with volumes, the server asks the person to confirm it, naming what goes; if they say no, nothing is done.
Inputs: folder (required), file, volumes. Returns: stopped
compose_execRun a command in a Compose serviceA
Run a command in a running service of a Compose project, returning its exit code and output. The command is a list; for a shell line, ["sh", "-c", "…"]. Can change the service: confirm with the person first unless it only reads.
Inputs: folder (required), command (required), service (required), file, +1 more. Returns: output, exitCode, truncated
compose_logsA Compose project's logsBRead-only
The last log lines of a Compose project's services (or one), 200 per service by default.
Inputs: folder (required), file, tail, service. Returns: output, truncated
compose_psA Compose project's servicesCRead-only
The services of a Compose project and their containers' state.
Inputs: folder (required), file. Returns: services
compose_upStart a Compose projectAIdempotent
Start a Compose project's services in the background (building what has a build), or only some. Runs whatever its compose file says, privileged services and host mounts included: read it first and confirm with the person, naming anything dangerous in it.
Inputs: folder (required), file, build, services. Returns: output, services, truncated
container_logsA container's logsARead-only
A container's last log lines (stdout and stderr), 200 by default; the start is left out when they're very long.
Inputs: container (required), tail, since. Returns: output, truncated
container_processesA container's processesARead-only
The processes running inside a container (docker top): their user, PID, start time, CPU time and command, with the columns Docker gives. The container must be running.
Inputs: container (required). Returns: columns, processes
container_statsContainers' resource usageARead-only
What containers consume right now, one snapshot (not a stream): CPU, memory (used, limit, percent), network and disk I/O, and processes. All running containers, or the ones named; a stopped one shows zeros. Use it to answer why the computer is slow or which container uses the most; container_processes shows what runs inside one.
Inputs: containers. Returns: containers
copy_from_containerCopy files out of a containerADestructiveIdempotent
Copy a container's file or folder to a local path. Overwrites what's there locally: confirm with the person first.
Inputs: to (required), from (required), container (required). Returns: copied
copy_to_containerCopy files into a containerADestructiveIdempotent
Copy a local file or folder into a container's path. Overwrites what's there: confirm with the person first.
Inputs: to (required), from (required), container (required). Returns: copied
create_networkCreate a networkA
Create a network, internal if it shouldn't reach the outside. Confirm with the person first.
Inputs: name (required), internal. Returns: created
create_volumeCreate a volumeA
Create a named volume, for data that outlives a container. Confirm with the person first.
Inputs: name (required). Returns: created
disk_usageDocker's disk usageARead-only
How much disk Docker uses for images, containers, volumes and the build cache, and how much of it could be reclaimed by prune.
Inputs: no named parameters. Returns: usage
docker_infoDocker's informationARead-only
Docker's version, the engine's operating system and architecture, its CPUs and memory, and how many containers (running, stopped) and images there are. A first call to check Docker is up.
Inputs: no named parameters. Returns: os, cpus, images, memory, +4 more
exec_in_containerRun a command in a containerA
Run a command in a running container and return its exit code and output (stdout and stderr together), stopped after timeoutSeconds. The command is a list, one argument per item; for a shell line, use ["sh", "-c", "…"]. Can change the container: confirm with the person first unless it only reads.
Inputs: command (required), container (required), env, user, +2 more. Returns: output, exitCode, truncated
inspect_containerInspect a containerARead-only
A container's details: image, command, state (with its exit code), ports, mounts, networks and labels, and the names of its environment variables (never their values, which may hold secrets).
Inputs: container (required). Returns: name, image, ports, state, +5 more
inspect_imageInspect an imageBRead-only
An image's details: tags, size, architecture, the command and entry point it runs, its exposed ports, working directory, volumes and labels.
Inputs: image (required). Returns: os, size, tags, labels, +6 more
inspect_networkInspect a networkBRead-only
A network's details: driver, subnet, whether it's internal, and the containers attached.
Inputs: network (required). Returns: details
inspect_volumeInspect a volumeBRead-only
A volume's details: driver, mount point, labels and when it was created.
Inputs: volume (required). Returns: details
lab_checkCheck a labAIdempotent
Run the lab's check (its lab.json) in its running service: passed when it exits 0, with its output to explain what failed. For a teacher, whether a statement or a solution works; for a student, whether their practice does. Runs inside the lab: confirm with the person first.
Inputs: lab (required). Returns: output, passed, exitCode, truncated
lab_downStop a labADestructiveIdempotent
Stop a lab and remove its containers, networks and volumes (what was done inside them is lost; the files in its folder stay). The server asks the person to confirm it, naming what goes; if they say no, nothing is done.
Inputs: lab (required). Returns: stopped
lab_execRun a command in a labA
Run a command in one of a running lab's services, returning its exit code and output. The command is a list; for a shell line, ["sh", "-c", "…"]. Can change the lab: confirm with the person first unless it only reads.
Inputs: lab (required), command (required), service (required), timeoutSeconds. Returns: output, exitCode, truncated
lab_logsA lab's logsBRead-only
The last log lines of a lab's services (or one), 200 per service by default.
Inputs: lab (required), tail, service. Returns: output, truncated
lab_resetReset a labADestructiveIdempotent
Back to a clean start: the lab's containers, networks and volumes are removed (what was done inside them is lost; the files in its folder stay) and it starts again. The server asks the person to confirm it, naming what goes; if they say no, nothing is done.
Inputs: lab (required). Returns: lab, services
lab_statusA lab's statusCRead-only
A lab's services and their containers' state (empty when it isn't running).
Inputs: lab (required). Returns: lab, services
lab_upStart a labAIdempotent
Start a lab under lab mode's policy: no privileged services, no host mounts but the lab's own folder, never the Docker socket, limits of 1 CPU and 512m per service, without internet (so the host can't reach its ports either: check it from inside with lab_exec). A lab that breaks the policy is refused with the reason. Confirm with the person first, saying what it will run (its services and images).
Inputs: lab (required). Returns: lab, services
list_containersList containersARead-only
List Docker containers, running or not (all unless running is true): id, name, image, state, status and ports. Names and ids are what the other container tools take.
Inputs: label, running. Returns: containers
list_imagesList imagesARead-only
List the local Docker images: id, repository, tag, size and when each was created.
Inputs: dangling. Returns: images
list_labsList the labsARead-only
List the labs: practices in the labs folder (/root/.docker-mcp/labs), each a folder with its compose.yaml and, optionally, a lab.json with the check that says whether it works.
Inputs: no named parameters. Returns: labs, labsDir
list_networksList networksARead-only
List Docker networks: id, name, driver and scope.
Inputs: no named parameters. Returns: networks
list_volumesList volumesARead-only
List Docker volumes: name, driver and where it lives.
Inputs: no named parameters. Returns: volumes
pruneClean up DockerADestructiveIdempotent
Remove what isn't in use: stopped containers, dangling images (all unused ones with allImages), unused networks, unused volumes (only when volumes is true: their data is gone) and the build cache. Says how much space it freed. Can't be undone. The server asks the person to confirm it, naming what goes; if they say no, nothing is done.
Inputs: what (required), volumes, allImages. Returns: output, truncated
pull_imagePull an imageAIdempotent
Download an image from its registry (Docker Hub unless it names another), e.g. postgres:17. Uses the network and disk: confirm with the person first.
Inputs: image (required). Returns: image, output, truncated
push_imagePush an imageAIdempotent
Upload a local image to its registry: Docker Hub unless its name starts with another (ghcr.io/owner/name:tag); give it that name first with tag_image. It publishes the image, maybe publicly: confirm with the person first, naming the registry and the tag. It uses the login the person made themselves with docker login; without one, it says what they must run in their own terminal. Never ask for their password or token.
Inputs: image (required). Returns: image, output, registry, truncated
remove_containerRemove a containerADestructiveIdempotent
Remove a container, with force to stop it first if it's running, and with volumes to remove its anonymous volumes. Its data is gone. The server asks the person to confirm it, naming what goes; if they say no, nothing is done.
Inputs: container (required), force, volumes. Returns: removed
remove_imageRemove an imageADestructiveIdempotent
Remove a local image (with force, even if a stopped container uses it). It has to be pulled or built again to be used. The server asks the person to confirm it, naming what goes; if they say no, nothing is done.
Inputs: image (required), force. Returns: removed
remove_networkRemove a networkADestructiveIdempotent
Remove a network (no container may be attached). The server asks the person to confirm it, naming what goes; if they say no, nothing is done.
Inputs: network (required). Returns: removed
remove_volumeRemove a volumeADestructiveIdempotent
Remove a volume and every file in it; can't be undone. The server asks the person to confirm it, naming what goes; if they say no, nothing is done.
Inputs: volume (required). Returns: removed
restart_containerRestart a containerAIdempotent
Restart an existing container. Confirm with the person first.
Inputs: container (required). Returns: state, container
run_containerRun a containerA
Create and start a container from an image (pulled if missing), in the background unless detach is false. Changes the machine: confirm with the person first. With dangerous options (privileged, the host's network, processes or IPC, extra capabilities, devices, mounting the Docker socket, the host's root or the person's home), the server also asks the person itself, saying what each gives the container; if they say no, it isn't run. To try something without it reaching the computer, isolate it: network "none", cpus, memory and pids limits, readOnly, noNewPrivileges, no ports or host folders, and a label to find and remove it later (list_containers filters by label). A foreground run (detach false) is stopped and removed when timeoutSeconds runs out.
Inputs: image (required), env, ipc, pid, +19 more. Returns: output, exitCode, timedOut, container, +1 more
server_infoServer infoARead-only
Show this server's name, version, mode (read, lab or full) and areas, who confirms removals and dangerous options, its labs and data folders, and whether Docker is there. Contains no secrets.
Inputs: no named parameters. Returns: mode, name, node, areas, +6 more
start_containerStart a containerBIdempotent
Start an existing container. Confirm with the person first.
Inputs: container (required). Returns: state, container
stop_containerStop a containerAIdempotent
Stop an existing container (it gets 10 seconds to stop cleanly). Confirm with the person first.
Inputs: container (required). Returns: state, container
tag_imageTag an imageAIdempotent
Give an image another name and tag (the image itself isn't copied). Confirm with the person first.
Inputs: tag (required), image (required). Returns: tag, image
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 47 tools
Tools are cleanly partitioned by resource family (container_, image_, volume_, network_, compose_, lab_) and the descriptions explicitly cross-reference near-neighbours (e.g. container_stats vs container_processes, lab_exec vs exec_in_container vs compose_exec). The parallel triples (logs/exec/status) share verb shapes but target different scopes, so an agent can pick correctly given the domain context. A couple of boundary cases remain, such as lab_status vs compose_ps vs list_containers, but they are resolvable from the descriptions.
The dominant pattern is verb_noun (list_images, inspect_volume, remove_network, pull_image, build_image, compose_up, lab_reset), and the inspect_/list_/create_/remove_ families are uniform. Deviations are the noun-first inspection tools (docker_info, server_info, disk_usage, container_logs, container_processes, container_stats) plus bare verbs like prune. Still predictable and grouped by prefix, so it reads well overall.
47 tools is well beyond the 15-tool comfort ceiling and makes the selection surface heavy for an agent. The count is largely justified by genuine domain breadth — six resource families each need list/inspect/create-or-run/remove plus lifecycle — and nothing looks redundant, but the set is at the borderline where prefix grouping becomes essential.
Coverage is strong across every family: containers (run/start/stop/restart/remove/logs/exec/inspect/stats/top/copy), images (pull/build/tag/push/remove/inspect/list), volumes and networks (full CRUD), plus Compose and the lab workflow with checks, resets, prune, disk usage and requirement checking. Gaps are minor: no network connect/disconnect, no pause/unpause or rename, no compose restart/pull, and no image search or event stream.
Maintenance
Related MCP Connectors
Remote Linux boxes for coding agents: Docker, a browser, screenshots, logs, human takeover.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
Manage your own cloud with AI: deploy apps, push and ship custom Docker images, manage resources via your AI agent.
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceEnables AI assistants to interact with Docker containers through safe, permission-controlled access to inspect, manage, and diagnose containers, images, and compose services with built-in timeouts and AI-powered analysis.-
- AlicenseAqualityBmaintenanceEnables AI assistants to manage Docker containers and Compose stacks through natural language, including lifecycle operations, logs, stats, and secure remote access.2113 npm3MIT
- AlicenseAqualityDmaintenanceEnables agentic Docker container operations including file read/write, command execution, and interactive TTY sessions via the local Docker binary.1910 npmMIT
- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to manage Docker containers and images, including starting, stopping, listing, and building operations.2-