Skip to main content
Glama
falkenslab
by falkenslab

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
DOCKER_MCP_MODENoMode 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_DIRNoPath 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
server_infoA

Show this server's name, version, mode (read, lab or full) and areas, 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: confirm with the person first, naming what goes.

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.

run_containerA

Create and start a container from an image (pulled if missing), in the background unless detach is false. 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) are refused unless confirmedDangerous is true: ask the person first, naming what they give the container. Changes the machine: confirm with the person first.

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: confirm with the person first, naming it.

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.

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: confirm with the person first, naming it.

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: confirm with the person first, naming it.

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). Confirm with the person first.

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_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, saying whether the data goes.

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. Confirm with the person first.

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). Confirm with the person first.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 43 tools

Disambiguation4/5

Core resource operations are clearly scoped (list/inspect/create/remove for containers, images, volumes, networks), and compose/lab variants name their target explicitly. The parallel exec/log/up tools across container, compose, and lab contexts are distinct by scope, though an agent must know which context applies to avoid misselection.

Naming Consistency4/5

Most tool names are snake_case with predictable verb_noun patterns for core resources (list_containers, inspect_image, remove_volume). Deviations exist for domain-prefixed compose/lab tools (compose_up, lab_exec) and a few noun-first info tools (container_logs, server_info, disk_usage), so the set is coherent but not uniformly verb_noun.

Tool Count2/5

43 tools is well above the 15-tool guideline and even beyond the 25-tool 'too many' threshold. While Docker is broad, many operations (separate list/inspect per resource, parallel compose/lab suites) could be consolidated.

Completeness4/5

The surface covers CRUD/lifecycle for containers, images, volumes, networks, Compose, and labs, including exec, logs, and copying. Minor gaps remain (image push, network connect/disconnect, container update), but agents can work around them.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive