container-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CONTAINER_MCP_READONLY | No | `1`/`true`: only listing, logs, and status work | off |
| CONTAINER_MCP_AGENT_NAME | No | Value of the `dev.container-mcp.agent` label on created containers | agent |
| CONTAINER_MCP_TIMEOUT_MS | No | Base CLI timeout in ms. Image pulls/builds and wait-mode runs get 600000 automatically. | 120000 |
| CONTAINER_MCP_DEFAULT_CPUS | No | CPU limit applied when the agent does not specify one | 2 |
| CONTAINER_MCP_ALLOWED_MOUNTS | No | Colon-separated allowlist of host paths agents may mount, copy to/from, or build from. Setting it replaces the default. | |
| CONTAINER_MCP_DEFAULT_MEMORY | No | Memory limit applied when the agent does not specify one | 2g |
| CONTAINER_MCP_MAX_CONTAINERS | No | Maximum concurrent containers run_container will create | 10 |
| CONTAINER_MCP_ALLOW_UNMANAGED | No | `1`/`true`: allow operating on containers not created by this server | off |
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 |
|---|---|
| list_containersA | List containers as JSON. Pass all: true to include stopped containers. |
| container_logsA | Fetch the most recent log lines from a container (default: last 100). The tail is applied server-side via the CLI -n flag. |
| run_containerA | Run a container inside its own lightweight VM. By default runs detached and returns the container ID. Pass wait: true to run to completion and return the container's output (10 minute limit). Mount sources must be inside the allowed host paths. Default CPU/memory limits are applied unless overridden. |
| stop_containerC | Stop a running container. |
| remove_containerA | Delete a container. Pass force: true to delete a running container. |
| exec_in_containerB | Run a command inside a running container and return its output. |
| container_statsA | Snapshot CPU, memory, and I/O usage for a container as JSON. |
| inspect_containerA | Full container details (configuration, mounts, labels, network, status) as JSON. |
| copy_filesA | Copy files between host and container. Container paths use ':'. Host paths must be inside the allowed roots. |
| list_imagesA | List local container images as JSON. |
| pull_imageB | Pull an OCI image from a registry, e.g. 'alpine:latest'. |
| build_imageB | Build an image from a Dockerfile. The build context must be inside an allowed host path. |
| remove_imageA | Delete a local image by reference. Pass force: true to remove even if in use. |
| prune_imagesA | Remove dangling images to reclaim disk. Pass all: true to remove all unused images. |
| system_statusA | Check whether the Apple container system service is running. Pass start: true to start it if it is stopped. |
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 15 tools
Each tool targets a distinct operation—containers vs images, lifecycle vs inspection vs logs—with no overlapping functionality. An agent can easily select the correct tool.
All tool names follow a consistent verb_noun pattern using snake_case, e.g., list_containers, run_container, pull_image. Minor variations like container_logs are still clear and predictable.
With 15 tools, the set is well-scoped for container management—covering containers, images, and system status without being overwhelming or sparse.
Covers essential container and image lifecycle operations (CRUD, logs, stats, exec, copy, pull, build, prune). Missing operations like commit or rename are tertiary; the surface is highly functional.