mcpdockery
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_containerA | Runs a Docker container locally for testing Args: image: Docker image to run, e.g. "nginx:latest" If no tag is specified, then usel alpine for default.It is smaller and faster to pull container_name: container name container_port: port the app listens on INSIDE the container, e.g. "80" for nginx host_port: port on your machine to access it, e.g. "8080" → http://localhost:8080 |
| stop_containerC | User will pass the container name that we need to stop Args: container_name: Docker Container name |
| list_containersB | Returns all containers with their status |
| delete_containerA | Delete a container by its name. Stops it first if it's still running. Destructive and irreversible. The first call (confirm=False, the default) does NOT delete anything — it only previews what would happen. Only pass confirm=True after the user has explicitly agreed to the deletion. Args: container_name: Container name that should be deleted confirm: must be True to actually perform the deletion (default False) |
| container_logsA | Collect and display the logs for a container. Values that look like secrets (PASSWORD=, "token": "...", etc.) are redacted before being returned. Args: container_name: Container name to collect logs tail: Number of log lines to return (default 200) |
| container_restartD | Restarting a container Args: container_name: name to restart the container |
| container_startC | Starting a container Args: container_name: name to start the container |
| container_statsA | Shows live CPU and memory usage for a running container. Args: container_name: Docker Container name |
| container_inspectB | Returns detailed information about a container: environment variables, mounts, network IP, and health status. Env var values that look like secrets (PASSWORD, TOKEN, API_KEY, etc.) are redacted. Args: container_name: Docker Container name |
| container_execA | Executes a shell command inside a running container and returns its output. Values that look like secrets (PASSWORD=, "token": "...", etc.) are redacted before being returned. Args: container_name: Docker Container name command: shell command to run inside the container, e.g. "ls -la /app" |
| deploy_stackA | Deploys a multi-container application from a docker-compose YAML definition. Args: project_name: unique name for this stack, used to group/manage its containers compose_yaml: full contents of a docker-compose.yml describing the services |
| stop_stackA | Stops all containers in a compose stack without removing them, so it can be started again later. Args: project_name: unique name for this stack, used to group/manage its containers |
| remove_stackA | Stops and permanently removes a compose stack: containers, networks, and volumes (data is deleted). The first call (confirm=False, the default) does NOT remove anything — it only previews what would happen. Only pass confirm=True after the user has explicitly agreed to the removal. Args: project_name: unique name for this stack, used to group/manage its containers confirm: must be True to actually perform the removal (default False) |
| list_stacksA | Lists all compose projects, including stopped ones |
| stack_statusA | Shows the status of all containers in a compose stack (like docker compose ps). Args: project_name: unique name for this stack, used to group/manage its containers |
| stack_logsA | Collects logs from all containers in a compose stack. Args: project_name: unique name for this stack, used to group/manage its containers tail: number of log lines to return per container (default 200) |
| list_imagesA | Lists all local Docker images, including untagged/intermediate ones. Each line shows: short ID, tags, and size in MB. |
| pull_imageA | Pulls a Docker image from a registry (Docker Hub, ECR, GCR, etc.) without
running it. Requires prior Defaults to the "alpine" tag (smaller, faster to pull) when no tag is specified. Only pass a different tag (e.g. "latest" or a specific version) if the user explicitly asks for the full/standard image — not every image publishes an "alpine" variant, in which case the pull will fail and you should retry with "latest". Args:
image: repository name, e.g. "nginx" or "myregistry.com:5000/my-app".
Can include a tag directly (e.g. "nginx:1.27"), in which case
the |
| delete_imageA | Delete a Docker image by tag or ID. Removed even if still referenced by a stopped container (force). Destructive and irreversible. The first call (confirm=False, the default) does NOT delete anything — it only previews what would happen. Only pass confirm=True after the user has explicitly agreed to the deletion. Args: image_name: image name to be deleted confirm: must be True to actually perform the deletion (default False) |
| build_imageA | Builds a Docker image from a Dockerfile already saved on disk. The build context is the folder containing the Dockerfile, so COPY/ADD of other files in that same folder works normally. Accepts either a Windows path ("C:\path\Dockerfile") or a Git Bash style path ("/c/path/Dockerfile"). Args: image_tag: tag to give the built image, e.g. "my-app:latest" dockerfile_path: full path to an existing Dockerfile on this machine |
| push_imageA | Tags a local Docker image with a registry repository name and pushes it
(e.g. Docker Hub, AWS ECR). Requires that you have already run |
| list_volumesA | Lists all Docker volumes with their driver and mountpoint |
| remove_volumeA | Deletes a Docker volume by name. Data stored in it is permanently lost. Fails if the volume is currently in use by a container. The first call (confirm=False, the default) does NOT delete anything — it only previews what would happen. Only pass confirm=True after the user has explicitly agreed to the deletion. Args: volume_name: name of the volume to remove confirm: must be True to actually perform the deletion (default False) |
| create_volumeC | Creates a new Docker volume. Args: volume_name: name to give the new volume driver: volume driver to use (default "local") |
| list_networksA | Lists all Docker networks with their driver and scope |
| create_networkA | Creates a new Docker network. Args: network_name: name to give the new network driver: network driver to use, e.g. "bridge" (default), "overlay" (swarm), "macvlan" |
| scan_imageA | Scans a Docker image for known vulnerabilities using Trivy. Requires the
Defaults to showing only CRITICAL and HIGH severity findings to keep the output compact. Widen it by passing e.g. severity="CRITICAL,HIGH,MEDIUM,LOW". Args: image: image to scan, e.g. "nginx:latest" or "my-app:v1" severity: comma-separated severities to include (default "CRITICAL,HIGH") |
| generate_sbomA | Generates a Software Bill of Materials (SBOM) for a Docker image using
Trivy — a full inventory of every OS package and language dependency the
image contains. Useful for supply-chain compliance, license audits, and
tracking exposure when a new CVE is disclosed (search the SBOM instead of
re-scanning). Requires the Args: image: image to generate an SBOM for, e.g. "nginx:latest" or "my-app:v1" format: SBOM format, "cyclonedx" (default) or "spdx-json" |
| scan_dockerfileA | Scans a Dockerfile for security misconfigurations using Trivy's config
scanner — BEFORE the image is even built. Flags things like: missing
USER directive (container would run as root), use of the "latest" tag,
hardcoded secrets in ENV/ARG, missing HEALTHCHECK, and use of ADD instead
of COPY. Requires the Args: dockerfile_path: full path to an existing Dockerfile on this machine. Accepts either a Windows path ("C:\path\Dockerfile") or a Git Bash style path ("/c/path/Dockerfile"). severity: comma-separated severities to include (default "CRITICAL,HIGH") |
| lint_dockerfileA | Lints a Dockerfile with Hadolint for best-practice and style issues —
unpinned package/base image versions, missing --no-install-recommends,
use of ADD instead of COPY, sudo usage, missing WORKDIR before relative
paths, and similar. Complements Args: dockerfile_path: full path to an existing Dockerfile on this machine. Accepts either a Windows path ("C:\path\Dockerfile") or a Git Bash style path ("/c/path/Dockerfile"). |
| audit_dockerfileA | Runs a full pre-build Dockerfile audit: Trivy's security misconfiguration
scan plus Hadolint's best-practice/style lint, combined into one report,
plus the raw Dockerfile content. Use this for a general "check/review/audit
my Dockerfile" request when the user hasn't specified security vs. style
specifically. For a narrower, single-tool check, use Args: dockerfile_path: full path to an existing Dockerfile on this machine. Accepts either a Windows path ("C:\path\Dockerfile") or a Git Bash style path ("/c/path/Dockerfile"). severity: comma-separated Trivy severities to include (default "CRITICAL,HIGH") |
| docker_doctorA | Scans every container and reports only the ones that need attention: OOM kills, restart loops, unhealthy health checks, crashed containers, or high CPU/memory usage. Returns a clean-bill-of-health message if nothing is flagged — use this instead of checking containers one by one. Args: cpu_threshold: CPU %% above which a running container is flagged (default 80.0) mem_threshold: memory %% of its limit above which a container is flagged (default 80.0) |
| check_exposed_portsA | Scans all running containers' published port bindings and flags anything worth a second look: known database/admin-panel ports (Postgres, MySQL, Redis, MongoDB, Elasticsearch, the Docker daemon API, etc.) and any port bound to 0.0.0.0/all interfaces rather than localhost. Meant to catch services that ended up reachable from the network when they were only meant for local access. Does not distinguish trusted vs. untrusted networks — a flagged binding may be fine on an isolated host, so review findings in context. |
| analyze_multistageA | Analyzes a Dockerfile and reports whether it would benefit from a multi-stage build. Detects build-tool commands (npm install/build, mvn, gradle, go build, cargo build, pip install with compilers, dotnet build/publish, make/cmake/gcc) combined with a single-stage FROM, which usually means build tools and dev dependencies end up shipped in the final image unnecessarily — increasing image size and attack surface. This tool only analyzes and returns reasoning plus the raw Dockerfile content — it does NOT generate the rewritten Dockerfile itself. If it reports multi-stage as recommended, use the returned content and detected build system to draft a multi-stage version yourself: a "builder" stage that runs the build commands, and a slim runtime stage that only COPYs the compiled artifact from the builder stage. Args: dockerfile_path: full path to an existing Dockerfile on this machine. Accepts either a Windows path ("C:\path\Dockerfile") or a Git Bash style path ("/c/path/Dockerfile"). |
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 34 tools
Most tools have clear, distinct purposes (e.g., container_logs vs. container_stats vs. docker_doctor), but a few overlap in intent (scan_dockerfile vs. lint_dockerfile vs. audit_dockerfile) and could confuse an agent if descriptions are not read carefully.
Naming is inconsistent: some tools use object_verb (container_logs, container_restart), others use verb_object (stop_container, delete_container), and some have no clear pattern (docker_doctor, generate_sbom). This makes it harder to predict tool names.
With 34 tools, the server is heavy for a typical MCP, but it covers a broad Docker domain comprehensively. Each tool has a distinct function, so the count is justified, though it exceeds the typical 3-15 range.
The toolset covers all major Docker operations: container lifecycle, image management, Dockerfile analysis, volumes, networks, and health/security checks. No obvious gaps for common Docker workflows.