What can you do with this server?

This server provides natural language control over a local Docker daemon, enabling LLMs to manage containers, images, volumes, networks, and Docker Compose stacks. * Containers: Run, stop, start, restart, force-delete, list, view logs, inspect details (env vars, mounts, network IPs, health), get live CPU/memory stats, and execute commands inside containers. * Images: List, build from a Dockerfile, push to a registry (Docker Hub, ECR, etc.), and force-delete. * Volumes & Networks: List volumes, remove volumes (permanently), and list networks. * Compose Stacks: Deploy from a docker-compose.yml, stop, remove (including containers, networks, and volumes), list all projects, check status, and collect logs.

Which integrations are available for this server?

Provides tools for managing Docker containers, images, volumes, networks, and Compose stacks through natural language.

How do I use dockhand?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dockhand run an nginx container mapping port 8080 to 80" 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.

dockhand

by Theo-Gkisis

Overview Schema Source Related Servers Discussions Admin

Python

Local

mcpdockery

An MCP server that gives an LLM (Claude, etc.) direct, natural-language control over your local Docker daemon — containers, images, volumes, networks, and Compose stacks.

Built with FastMCP and the Docker SDK for Python.

Related MCP server: Docker MCP Server

Requirements

Requirement	Notes
Python >= 3.14	Interpreter version pinned in `.python-version`
Docker	Docker Desktop or Docker Engine, running locally
Docker Compose v2 CLI	`docker compose` must be available on `PATH` — required for the stack/compose tools
Trivy	`trivy` must be available on `PATH` — required for the `scan_image` and `scan_dockerfile` tools
Hadolint	`hadolint` must be available on `PATH` — required for the `lint_dockerfile` tool
uv	Used for dependency management and running the server

For pulling from or pushing to a private registry (Docker Hub, AWS ECR, GCR, etc.), authenticate with that registry beforehand using your normal docker login flow — this server never accepts or stores credentials itself.

Installation

Clone the repository:
```
git clone <this-repo>
cd mcpdockery
```
Install dependencies:
```
uv sync
```
This creates a .venv and installs the exact dependency versions pinned in uv.lock.
Confirm Docker is running:
```
docker info
```
If this command fails, start Docker Desktop (or your Docker Engine) before continuing.

Running the server

uv run src/main.py

The server communicates over stdio, so it's meant to be launched by an MCP client rather than run standalone in a terminal.

Connecting to an MCP client

Add an entry to your MCP client's configuration (e.g. claude_desktop_config.json for Claude Desktop, or your project's .mcp.json for Claude Code):

{
  "mcpServers": {
    "mcpdockery": {
      "command": "uv",
      "args": ["--directory", "/absolute/path/to/mcpdockery", "run", "src/main.py"]
    }
  }
}

Replace /absolute/path/to/mcpdockery with the actual path where you cloned the repository, then restart the client. The tools listed below will become available to the model.

Available tools

Containers (`containers.py`)

Tool	Description
`run_container`	Runs a container from an image, mapping a container port to a host port
`stop_container`	Stops a running container
`container_start`	Starts a stopped container
`container_restart`	Restarts a container
`delete_container`	Force-removes a container (stops it first if needed). Destructive — requires `confirm=True`; the first call only previews what would be deleted
`list_containers`	Lists all containers and their status
`container_logs`	Fetches the last N log lines from a container. Secret-shaped values (passwords, tokens, API keys) are redacted
`container_stats`	Reports live CPU % and memory usage
`container_inspect`	Shows env vars, mounts, network IPs, and health status. Secret-shaped env values are redacted
`container_exec`	Executes a shell command inside a running container. Secret-shaped values in the output are redacted

Images (`images.py`)

Tool	Description
`list_images`	Lists all local images, including untagged/intermediate ones, with size
`pull_image`	Pulls an image from a registry without running it; defaults to the `alpine` tag unless a different tag is requested
`build_image`	Builds an image from a Dockerfile already on disk
`push_image`	Tags and pushes a local image to a registry (requires prior `docker login`)
`delete_image`	Force-removes a local image. Destructive — requires `confirm=True`; the first call only previews what would be deleted

Volumes (`volumes.py`)

Tool	Description
`list_volumes`	Lists volumes with driver and mountpoint
`create_volume`	Creates a new volume
`remove_volume`	Deletes a volume (fails if still in use). Destructive — requires `confirm=True`; the first call only previews what would be deleted

Networks (`networks.py`)

Tool	Description
`list_networks`	Lists networks with driver and scope
`create_network`	Creates a new network

Optimization (`optimization.py`)

Tool	Description
`analyze_multistage`	Detects whether a Dockerfile would benefit from a multi-stage build (build-tool commands in a single-stage image); returns reasoning + raw content for the model to draft the rewrite

Diagnostics (`diagnostics.py`)

Tool	Description
`docker_doctor`	Scans all containers and reports only the ones needing attention: OOM kills, restart loops, unhealthy checks, crashes, high CPU/memory
`check_exposed_ports`	Flags running containers with sensitive ports (databases, admin panels, Docker daemon API) or any port bound to all network interfaces

Security (`security.py`)

Tool	Description
`scan_image`	Scans an image for known vulnerabilities using Trivy; defaults to CRITICAL/HIGH severity only
`generate_sbom`	Generates a Software Bill of Materials (SBOM) for an image using Trivy, in CycloneDX or SPDX-JSON format
`scan_dockerfile`	Scans a Dockerfile for misconfigurations (root user, `latest` tag, hardcoded secrets, missing HEALTHCHECK, etc.) before it's even built
`lint_dockerfile`	Lints a Dockerfile with Hadolint for best-practice/style issues (unpinned versions, `ADD` vs `COPY`, missing `--no-install-recommends`, etc.)
`audit_dockerfile`	Combined report: `scan_dockerfile` + `lint_dockerfile` + raw file content, so the model can also draft a corrected Dockerfile — use for a general "check my Dockerfile" request

Compose stacks (`stacks.py`)

Tool	Description
`deploy_stack`	Deploys a stack from an inline `docker-compose.yml` (`compose up -d`)
`stop_stack`	Stops a stack's containers without removing them
`remove_stack`	Stops and removes a stack, including its volumes (`compose down -v`). Destructive — requires `confirm=True`; the first call only previews what would be removed
`list_stacks`	Lists all compose projects, including stopped ones
`stack_status`	Shows the status of a stack's containers (`compose ps`)
`stack_logs`	Collects logs from every container in a stack

Usage examples

Once connected, you can drive the server with natural-language requests. A few examples of what to expect:

You ask	Tool(s) the model will likely use
"Pull the alpine version of redis"	`pull_image`
"Run an nginx container on port 8080"	`run_container`
"Show me the logs for my-app from the last hour"	`container_logs`
"What's using all the CPU right now?"	`list_containers`, `container_stats`
"Is anything broken right now?"	`docker_doctor`
"Is anything exposed to the network that shouldn't be?"	`check_exposed_ports`
"Deploy this docker-compose file as 'staging'"	`deploy_stack`
"Push my-app:latest to my ECR repo"	`push_image`
"Clean up the my-app container and its image"	`delete_container`, `delete_image`
"Scan my-app:latest for vulnerabilities"	`scan_image`
"Generate an SBOM for my-app:latest"	`generate_sbom`
"Check my Dockerfile for security issues before I build it"	`scan_dockerfile`
"Lint my Dockerfile for best practices"	`lint_dockerfile`
"Check/review my Dockerfile"	`audit_dockerfile`
"Should this Dockerfile use multi-stage builds?"	`analyze_multistage`

The model chooses which tool(s) to call based on your request — you don't need to name the tool yourself.

Project structure

src/
  main.py             # Entrypoint: registers tool modules and starts the MCP server
  server.py           # Shared FastMCP server instance
  docker_client.py    # Lazy singleton Docker SDK client
  compose_client.py   # Thin wrapper around the `docker compose` CLI
  helper.py           # Shared helpers (path normalization, image tag parsing, Trivy wrapper)
  containers.py       # Container lifecycle & inspection tools
  images.py           # Image pull/build/push/list/delete tools
  volumes.py          # Volume tools
  networks.py         # Network tools
  stacks.py           # Compose stack tools
  security.py         # Image/Dockerfile vulnerability & misconfiguration scanning tools
  diagnostics.py      # Cross-container health triage tools
  optimization.py     # Dockerfile efficiency analysis tools

Safety notes

This server gives the model real, unsandboxed control over your Docker daemon:

delete_container, delete_image, remove_volume, and remove_stack are destructive and require an explicit confirm=True argument. The first call (confirm defaults to False) performs no action and only returns a preview of what would be deleted — the model is instructed to only pass confirm=True after you've explicitly agreed in the conversation. This is a safety net against a misread request, not a hard permission system: any client with tool access can still pass confirm=True directly.
remove_stack deletes volumes (-v), which is destructive and irreversible for stateful data.
container_exec runs arbitrary shell commands inside a container.
container_logs, container_exec, and container_inspect redact values that look like secrets (keys matching PASSWORD/TOKEN/API_KEY/etc., in KEY=value, KEY: value, or "key": "value" form) before returning them. This is a best-effort heuristic, not a guarantee — anything that doesn't match the pattern (or that a container prints in an unusual format) is returned as-is, and remember that tool output is sent to the model provider as part of the conversation regardless of how "local" the Docker daemon is.
push_image and pull_image use your existing local Docker credentials — the model can push to or pull from any registry you're currently authenticated with. Note that AWS ECR tokens expire after 12 hours; if a push/pull suddenly fails with an auth error, re-run your docker login / aws ecr get-login-password flow rather than assuming the tool is broken.
The Docker socket grants root-equivalent access to the host. Giving a model tool access to this server is equivalent to giving it that level of access to your machine, whether or not the daemon is reachable over the network.

Only connect this server to clients/agents you trust, and be deliberate about which containers and stacks you let it touch.

License

No license specified.

Available Tools

23 tools

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

Inputs: image_tag (required), dockerfile_path (required). Returns: result

container_execB

Executes a shell command inside a running container and returns its output. Args: container_name: Docker Container name command: shell command to run inside the container, e.g. "ls -la /app"

Inputs: command (required), container_name (required). Returns: result

container_inspectA

Returns detailed information about a container: environment variables, mounts, network IP, and health status. Args: container_name: Docker Container name

Inputs: container_name (required). Returns: result

container_logsB

Collect and display the logs for a container Args: container_name: Container name to collect logs tail: Number of log lines to return (default 200)

Inputs: container_name (required), tail. Returns: result

container_restartD

Restarting a container Args: container_name: name to restart the container

Inputs: container_name (required). Returns: result

container_startC

Starting a container Args: container_name: name to start the container

Inputs: container_name (required). Returns: result

container_statsA

Shows live CPU and memory usage for a running container. Args: container_name: Docker Container name

Inputs: container_name (required). Returns: result

delete_containerA

Delete a container by its name. Stops it first if it's still running. Args: container_name: Container name that should be deleted

Inputs: container_name (required). Returns: result

delete_imageA

Delete a Docker image by tag or ID. Removed even if still referenced by a stopped container (force). Args: image_name: image name to be deleted

Inputs: image_name (required). Returns: result

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

Inputs: compose_yaml (required), project_name (required). Returns: result

list_containersB

Returns all containers with their status

Inputs: no named parameters. Returns: result

list_imagesA

List all Docker images

Inputs: no named parameters. Returns: result

list_networksA

Lists all Docker networks with their driver and scope

Inputs: no named parameters. Returns: result

list_stacksA

Lists all compose projects, including stopped ones

Inputs: no named parameters. Returns: result

list_volumesA

Lists all Docker volumes with their driver and mountpoint

Inputs: no named parameters. Returns: result

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 docker login locally — this tool does not accept credentials. Args: local_image: the image currently on your machine, e.g. "my-app:latest" repository: full destination repository name, e.g. "myusername/my-app" or "123456789012.dkr.ecr.eu-west-1.amazonaws.com/my-app" image_tag: tag to push, e.g. "latest" or "v1.0"

Inputs: repository (required), local_image (required), image_tag. Returns: result

remove_stackA

Stops and permanently removes a compose stack: containers, networks, and volumes (data is deleted). Args: project_name: unique name for this stack, used to group/manage its containers

Inputs: project_name (required). Returns: result

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. Args: volume_name: name of the volume to remove

Inputs: volume_name (required). Returns: result

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

Inputs: image (required), host_port (required), container_name (required), container_port (required). Returns: result

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)

Inputs: project_name (required), tail. Returns: result

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

Inputs: project_name (required). Returns: result

stop_containerC

User will pass the container name that we need to stop Args: container_name: Docker Container name

Inputs: container_name (required). Returns: result

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

Inputs: project_name (required). Returns: result

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

Deploy Server

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

B3.4/5.0

Scored 2026-07-16 18:10 across 23 tools

Disambiguation5/5

Each tool targets a distinct Docker operation (image build, container exec, stats, logs, stack management, etc.), with clear descriptions that prevent confusion. The only potential overlap is between container_start and run_container, but descriptions clarify that one starts an existing container and the other creates and starts a new one.

Naming Consistency3/5

Naming conventions are mixed: some tools use verb_noun (build_image, delete_container), others use noun_verb (container_exec, container_inspect), and list tools use list_noun. While individually readable, the lack of a unified pattern (e.g., all verb_noun or all noun_verb) makes it harder to predict tool names.

Tool Count4/5

With 23 tools covering images, containers, volumes, networks, and stacks, the number is appropriate for a Docker management server. It's comprehensive but not overwhelming, though a few tools (like list_networks and list_volumes) could be merged without loss of clarity.

Completeness4/5

Core Docker workflows are well-covered: building/pushing images, running/executing/inspecting containers, managing stacks. However, missing network creation/removal and volume creation mean agents may hit dead ends when trying to set up isolated test environments.

Maintenance

ActivityInactive

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

mcp-aichat
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
https://aichat.mcp.acedata.cloud/mcp
mcp-openai
io.github.AceDataCloud
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
AI & Machine Learning Image & Video Processing
11
https://openai.mcp.acedata.cloud/mcp
supportsheep
io.github.itsryanarmani
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Content Management Systems Marketing AI & Machine Learning
1
https://supportsheep.com/api/v1/mcp
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
https://supportsheep.com/api/v1/mcp

Related MCP Servers

ChatGPT MCP Server
Virtualization Code Execution
Toowiredd
F
license
A
quality
F
maintenance
A Model Context Protocol server that enables Docker container management through natural language interactions using a custom GPT interface.
Updated a year ago (2025-07-22 13:12 UTC)
7
15
-
Docker MCP Server
Virtualization Developer Tools Command Line
RodrigoUC
A
license
Not graded
quality
D
maintenance
An MCP server that enables managing Docker containers through natural language commands, allowing users to create, list, and delete containers. It facilitates automated container orchestration and integrates with VS Code via the Cline extension.
Updated 8 months ago (2026-03-10 03:54 UTC)
86 npm
MIT
Docker MCP Server
Virtualization Command Line Databases
hypnosis
A
license
A
quality
B
maintenance
Universal Docker MCP server for AI assistants (Cursor, Claude Desktop). Manage Docker containers, execute commands, query databases, and handle environment configurations — all through natural language.
Updated 3 months ago (2026-08-24 20:37 UTC)
10
277 npm
1
MIT
Docker Container Manager MCP
Virtualization Monitoring
Festuskipkoech
F
license
Not graded
quality
D
maintenance
An MCP server that gives any LLM client the ability to list, inspect, start, stop, and monitor Docker containers on the host machine.
Updated 4 months ago (2026-07-11 03:55 UTC)
1
-

mcpdockery

Table of contents

Requirements

Installation

Running the server

Connecting to an MCP client

Available tools

Containers (containers.py)

Images (images.py)

Volumes (volumes.py)

Networks (networks.py)

Optimization (optimization.py)

Diagnostics (diagnostics.py)

Security (security.py)

Compose stacks (stacks.py)

Usage examples

Project structure

Safety notes

License

Available Tools

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

ChatGPT MCP Server

Docker MCP Server

Docker MCP Server

Docker Container Manager MCP

Containers (`containers.py`)

Images (`images.py`)

Volumes (`volumes.py`)

Networks (`networks.py`)

Optimization (`optimization.py`)

Diagnostics (`diagnostics.py`)

Security (`security.py`)

Compose stacks (`stacks.py`)