docker-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DOCKER_MCP_MODE | No | Mode of operation chosen at startup: 'read' only looks, 'lab' only runs labs under a safety policy, and 'full' does everything Docker does (asking before anything dangerous). A tool outside the mode does not exist for the agent. | full |
| DOCKER_MCP_LABS_DIR | No | Path to the folder containing the practice labs (each with a compose.yaml and a check). Used in 'lab' mode. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| server_infoA | 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. |
| check_requirementsA | 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. |
| docker_infoA | 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. |
| disk_usageA | How much disk Docker uses for images, containers, volumes and the build cache, and how much of it could be reclaimed by prune. |
| pruneA | 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. |
| list_containersA | 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. |
| inspect_containerA | 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). |
| container_logsA | A container's last log lines (stdout and stderr), 200 by default; the start is left out when they're very long. |
| container_statsA | 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. |
| container_processesA | 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. |
| run_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. |
| start_containerB | Start an existing container. Confirm with the person first. |
| stop_containerA | Stop an existing container (it gets 10 seconds to stop cleanly). Confirm with the person first. |
| restart_containerA | Restart an existing container. Confirm with the person first. |
| remove_containerA | 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. |
| exec_in_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. |
| copy_to_containerA | Copy a local file or folder into a container's path. Overwrites what's there: confirm with the person first. |
| copy_from_containerA | Copy a container's file or folder to a local path. Overwrites what's there locally: confirm with the person first. |
| list_imagesA | List the local Docker images: id, repository, tag, size and when each was created. |
| inspect_imageB | An image's details: tags, size, architecture, the command and entry point it runs, its exposed ports, working directory, volumes and labels. |
| pull_imageA | 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. |
| build_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. |
| tag_imageA | Give an image another name and tag (the image itself isn't copied). Confirm with the person first. |
| push_imageA | 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. |
| remove_imageA | 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. |
| list_volumesA | List Docker volumes: name, driver and where it lives. |
| inspect_volumeB | A volume's details: driver, mount point, labels and when it was created. |
| create_volumeA | Create a named volume, for data that outlives a container. Confirm with the person first. |
| remove_volumeA | 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. |
| list_networksA | List Docker networks: id, name, driver and scope. |
| inspect_networkB | A network's details: driver, subnet, whether it's internal, and the containers attached. |
| create_networkA | Create a network, internal if it shouldn't reach the outside. Confirm with the person first. |
| remove_networkA | 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. |
| compose_psC | The services of a Compose project and their containers' state. |
| compose_logsB | The last log lines of a Compose project's services (or one), 200 per service by default. |
| compose_buildA | 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. |
| compose_upA | 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. |
| compose_downA | 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. |
| compose_execA | 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. |
| list_labsA | 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. |
| lab_statusC | A lab's services and their containers' state (empty when it isn't running). |
| lab_logsB | The last log lines of a lab's services (or one), 200 per service by default. |
| lab_upA | 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). |
| lab_execA | 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. |
| lab_checkA | 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. |
| lab_resetA | 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. |
| lab_downA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 47 tools
Most tools target distinct resources and actions (containers, images, volumes, networks, compose, labs), and descriptions clarify boundaries. However, the lab_* group closely mirrors compose_* operations (lab_up vs compose_up, lab_exec vs compose_exec, lab_logs vs compose_logs), and bulk cleanup tools like prune overlap conceptually with individual remove_* tools, which could cause occasional misselection.
The dominant pattern is verb_noun snake_case (list_containers, remove_network, create_volume), which is applied consistently across most tool families. Deviations include resource-first names like container_logs, container_stats, and container_processes, plus compose_ps instead of a list-style verb, but the overall scheme remains predictable.
With 47 tools, the surface is heavy for a Docker management server and exceeds the typical well-scoped range. Many operations are naturally grouped (container lifecycle, image lifecycle, compose, labs), and some could be consolidated without losing capability.
Coverage is broad: complete container lifecycle (run, start, stop, restart, remove, exec, copy, logs, stats, processes, inspect), image operations, volume and network CRUD, compose lifecycle, and lab workflows. Minor gaps exist (e.g., container pause/unpause, rename/update, image save/load, network connect/disconnect), but core workflows are well supported.