Docker MCP Server
OCI · GHCR.IO/L337-ORG/DOCKER-MCP-SERVER:2.2.6 · 3 COMPONENTS · SCANNED SEP 21
Manage Docker (containers, images, Compose, Swarm, registries) via the Docker SDK and CLI.
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security0
- Malware scan not yet available for this package.Unverified
- Known CVEs could not be checked: this artifact ships no SBOM, so there is no dependency list to read. Publishing one would let us assess it.Unverified
- Install-script risk not yet assessed.Unverified
- Dependency health could not be checked: this artifact ships no SBOM, so there is no dependency list to read. Publishing one would let us assess it.Unverified
Provenance & Transparency35
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: no license is declared. See how to fix → Fail
- Actively maintained (last published 10 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability75
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 40054 tokens (~238/item across 168 items; 165 tools + 3 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management37
- Stability observed for 11 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (23% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 17 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 167 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
Unverified: 1 category
A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.
How do I install the Docker MCP Server server?
Docker MCP Server runs locally as a container image, launched with docker run --rm -i ghcr.io/l337-org/docker-mcp-server:2.2.6. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation.
oci · ghcr.io/l337-org/docker-mcp-server:2.2.6
claude mcp add l337-org-docker-mcp-server -- docker run --rm -i ghcr.io/l337-org/docker-mcp-server:2.2.6
{
"mcpServers": {
"l337-org-docker-mcp-server": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"ghcr.io/l337-org/docker-mcp-server:2.2.6"
]
}
}
} {
"servers": {
"l337-org-docker-mcp-server": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"ghcr.io/l337-org/docker-mcp-server:2.2.6"
]
}
}
} codex mcp add l337-org-docker-mcp-server -- docker run --rm -i ghcr.io/l337-org/docker-mcp-server:2.2.6
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"l337-org-docker-mcp-server": {
"type": "local",
"command": [
"docker",
"run",
"--rm",
"-i",
"ghcr.io/l337-org/docker-mcp-server:2.2.6"
],
"enabled": true
}
}
} mcp_servers:
l337-org-docker-mcp-server:
command: "docker"
args: ["run", "--rm", "-i", "ghcr.io/l337-org/docker-mcp-server:2.2.6"] {
"McpServers": {
"l337-org-docker-mcp-server": {
"Transport": "stdio",
"Command": "docker",
"Arguments": [
"run",
"--rm",
"-i",
"ghcr.io/l337-org/docker-mcp-server:2.2.6"
]
}
}
} {
"mcpServers": {
"l337-org-docker-mcp-server": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"ghcr.io/l337-org/docker-mcp-server:2.2.6"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Sept 26 +4
- Stability: unverified → 0.30 ▲ functional
- 10 Sept 26 36
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Analysed oci/ghcr.io/l337-org/docker-mcp-server:2.2.6
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | oci |
| Reason | No attestation published |
Background: How many MCP packages publish verified provenance →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
container_logs ~454
Get the logs of a container: a one-shot snapshot by default, or a bounded live tail with `follow=True`. Follow mode returns when `limit_lines` lines are collected, `timeout_seconds` elapses, or the container exits, whichever comes first - so the agent can watch live output without blocking forever. `limit_lines`/`timeout_seconds` apply only in follow mode; `until` only in snapshot mode. Snapshot mode is capped at 32 MiB and raises ToolInputError past it, so a noisy container can't exhaust the server's memory; `service_logs` caps the same way and lets the caller raise it. Prefer an integer `tail`, or `since`, over `tail="all"` on a long-running container: "all" is safe but will abort on the cap rather than returning a partial answer, and a large result can still exceed the agent's context. Caveat for `ssh://` daemons: docker-py can't cancel an SSH stream, so in follow mode the `timeout_seconds` watchdog can't interrupt a fully silent container - use the snapshot mode there if you need a hard time bound. Args: tail: Number of lines from the end, or the literal "all" for everything since: Only return logs created after this unix timestamp until: Only return logs created before this unix timestamp (snapshot mode only) follow: Follow the live log stream instead of returning a snapshot limit_lines: Follow mode: max lines to collect before returning timeout_seconds: Follow mode: max wall-clock seconds before returning what was collected Returns: str: Decoded log output (up to `limit_lines` lines in follow mode). Raises ToolInputError in snapshot mode if the logs exceed 32 MiB.
| Name | Type | Req | Description |
|---|---|---|---|
| follow | boolean | – | – |
| id_or_name | string | yes | – |
| limit_lines | integer | – | – |
| since | number | – | – |
| stderr | boolean | – | – |
| stdout | boolean | – | – |
| tail | – | – | – |
| timeout_seconds | number | – | – |
| timestamps | boolean | – | – |
| until | number | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
container_pause ~116
Suspend all processes in a container using the kernel freezer cgroup. Unlike sending SIGSTOP, the freezer cgroup suspends processes without their being able to observe or intercept the suspension. A paused container keeps its resources (memory, open file descriptors) but consumes no CPU. Resume with `container_unpause` - `container_exec` fails against a paused container until it is unpaused. Returns: dict: The container's full inspect payload after pause (State.Paused true)
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
No output schema declared.
No examples provided.
container_prune ~158
Remove all stopped containers to reclaim disk space. Only removes containers that are not running - running containers are never affected. Use `container_list(all=True)` to preview what would be removed before calling this. Valid filter keys: `until` (RFC3339 timestamp or duration like "24h" - removes containers stopped before that point), `label` (key or key=value). For a broader cleanup of containers plus unused images, networks, and volumes see the `prune_managed` prompt. Args: filters: Narrow which stopped containers to remove; omit to remove all stopped Returns: dict: {"ContainersDeleted": [...], "SpaceReclaimed": <bytes>}
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | – | – |
No output schema declared.
No examples provided.
container_remove ~162
Remove a container, deleting its writable layer. The image is untouched (`image_remove` deletes images); named volumes are never removed - volumes=True only covers anonymous ones. A running container is refused unless force=True, which kills it first. When the server runs containerized it refuses to remove its own container. Args: volumes: Also remove anonymous volumes (the CLI's `--volumes`); named volumes persist link: Remove the specified link force: Kill a running container before removing it (default False: running is an error) Returns: bool: True after removal completes
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | – | – |
| id_or_name | string | yes | – |
| link | boolean | – | – |
| volumes | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | – |
No examples provided.
container_rename ~133
Rename a container in place; its id, state, and configuration are unchanged. Use it to free up or claim a container name (names are unique per daemon) - e.g. before starting a replacement under the old name. Fails with a conflict error if the new name is already taken. Not related to `image_tag`, which names images. Args: name: The new name; must not be in use by any other container Returns: dict: The container's full inspect payload after the rename
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
| name | string | yes | – |
No output schema declared.
No examples provided.
container_restart ~133
Restart a container: stop then start again in one call. The container receives its configured stop signal (`STOPSIGNAL`, default SIGTERM), SIGKILL after stop_timeout_seconds, and is then started. Use `container_stop`/`container_start` to do the halves separately. When the server runs containerized it refuses to restart its own container. Args: stop_timeout_seconds: Seconds between the stop signal and SIGKILL Returns: dict: The container's full inspect payload after the restart
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
| stop_timeout_seconds | integer | – | – |
No output schema declared.
No examples provided.
container_run ~595
Run a container from an image (create and start in one call, like `docker run`). Use `container_create` to prepare a container without starting it, or `container_exec` to run a command in a container that already exists. With detach=False the call blocks until the container exits and returns its output, so long-running images need detach=True. Created containers are stamped with provenance labels. Args: command: The command to run in the container name: Name to assign to the container detach: Run in the background and return container info environment: Environment variables, as `{"KEY": "value"}` or a list of "KEY=value" strings ports: Port mappings, e.g. {'2222/tcp': 3333} volumes: Volumes to mount, as `{"/host/path": {"bind": "/in/container", "mode": "rw"}}` or a list of "host:container:mode" strings network: Name of the network to attach hostname: Hostname for the container user: Username or UID to run as working_dir: Working directory inside the container entrypoint: Entrypoint to override the image default restart_policy: Restart policy, e.g. {'Name': 'on-failure', 'MaximumRetryCount': 3} labels: Labels to set on the container remove: Remove the container when it exits (only with detach=False) auto_remove: Enable auto-removal of the container on daemon side privileged: Give extended privileges to the container tty: Allocate a pseudo-TTY mem_limit: Memory limit: bytes as an int, or a units string ("100000b", "1000k", "128m", "1g") cpu_count: Number of CPUs extra_kwargs: Additional keyword arguments forwarded to ContainerCollection.run (call `docs_lookup(section="containers")` for the full accepted set) Returns: dict | str: The container's full inspect payload when detach=True, else stdout/stderr as a string
| Name | Type | Req | Description |
|---|---|---|---|
| auto_remove | boolean | – | – |
| command | – | – | – |
| cpu_count | integer | – | – |
| detach | boolean | – | – |
| entrypoint | – | – | – |
| environment | – | – | – |
| extra_kwargs | object | – | – |
| hostname | string | – | – |
| image | string | yes | – |
| labels | – | – | – |
| mem_limit | – | – | – |
| name | string | – | – |
| network | string | – | – |
| ports | object | – | – |
| privileged | boolean | – | – |
| remove | boolean | – | – |
| restart_policy | – | – | – |
| stdin_open | boolean | – | – |
| tty | boolean | – | – |
| user | string | – | – |
| volumes | – | – | – |
| working_dir | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
container_start ~123
Start an existing stopped container. Use this to restart a container that was previously created or stopped without removing it. To create and start a new container in one step use `container_run` instead. Calling on an already-running container has no effect (the daemon returns 304 and no error is raised). To stop then start a running container use `container_restart`. Args: id_or_name: Container id (full or short) or name Returns: dict: The container's full inspect payload after starting
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
No output schema declared.
No examples provided.
container_stats ~249
Get one point-in-time resource-usage snapshot for a container (non-streaming). Returns the raw engine stats payload; CPU percent must be computed from the delta between `cpu_stats` and `precpu_stats`. By default the daemon collects two cycles before answering, which is what fills `precpu_stats` - so the call takes about a second. `one_shot=True` returns after a single collection instead, leaving `precpu_stats` zeroed and CPU percent uncomputable; use it when only `memory_stats`/`pids_stats` matter. For a pre-computed human-readable summary prefer the `docker-stats://{id_or_name}` resource; for a process listing use `container_top`. Args: one_shot: Skip the second collection cycle for a faster answer, at the cost of an empty `precpu_stats` (so no CPU percent); needs daemon API v1.41+ Returns: dict: Engine stats payload (read, cpu_stats, precpu_stats, memory_stats, networks, pids_stats, ...)
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
| one_shot | boolean | – | – |
No output schema declared.
No examples provided.
container_stop ~174
Gracefully stop a running container (its configured stop signal, then SIGKILL after a timeout). Prefer this over `container_kill` for a clean shutdown: the main process receives the container's stop signal (`STOPSIGNAL`, default SIGTERM) and has stop_timeout_seconds to exit before the daemon force-kills it. Use `container_restart` to stop and start again in one call, or `container_pause` to freeze processes without stopping. When the server runs containerized it refuses to stop its own container. Args: stop_timeout_seconds: Seconds between the stop signal and SIGKILL Returns: dict: The container's full inspect payload after the stop (exit code under State.ExitCode)
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
| stop_timeout_seconds | integer | – | – |
No output schema declared.
No examples provided.
container_top ~151
List the processes running inside a container (the daemon runs `ps` on the host). Works on any running container without executing anything in it, so it needs no shell or `ps` binary in the image - unlike `container_exec` with `ps`. Use `container_stats` for resource usage rather than process lists. Fails if the container is not running. Args: ps_args: Extra ps arguments (e.g. "aux"); default is the daemon's standard ps invocation Returns: dict: {"Titles": [ps column names], "Processes": [[one row of values per process]]}
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
| ps_args | string | – | – |
No output schema declared.
No examples provided.
container_unpause ~91
Resume all processes in a paused container (the reverse of `container_pause`). Only valid on a paused container - it fails if the container is merely stopped; use `container_start` for stopped containers. Processes continue from where they were frozen. Returns: dict: The container's full inspect payload after unpause (State.Paused becomes false)
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
No output schema declared.
No examples provided.
container_update ~247
Update resource limits on a container without recreating it. Changes take effect immediately on Linux (cgroups); not all fields are updatable on every platform. Common `updates` keys: `mem_limit` (bytes, e.g. 134217728 for 128 MB), `memswap_limit` (memory+swap in bytes; -1 = unlimited), `cpu_shares` (relative weight, default 1024), `cpu_period` / `cpu_quota` (microseconds for CFS throttling), `cpuset_cpus` (e.g. "0-1"), `restart_policy` (dict with `Name` such as "on-failure"/"always"/"unless-stopped" and optional `MaximumRetryCount`). To change image, env, or volumes the container must be recreated (`container_remove` + `container_run`). Args: id_or_name: Container id or name to update updates: Resource fields to update; see description for valid keys Returns: dict: The container's full inspect payload after the update
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
| updates | object | yes | – |
No output schema declared.
No examples provided.
container_wait ~682
Block until a container reaches a condition: stopped, "healthy", or its logs contain a pattern. One contract for every mode: never raises on timeout - the result always carries `met` (condition reached) and `timed_out`. The stop conditions ("not-running"/"next-exit"/"removed") use the daemon's blocking wait and fill `status_code`/`error` (the container's exit info); "healthy" polls the container's HEALTHCHECK every `poll_interval`s and fills `health`/`status`; "log-match" polls recent logs every `poll_interval`s for `pattern` and fills `matched_line`. For a compose project use `compose_wait`; for swarm services use `service_wait`. Health semantics: with no HEALTHCHECK defined, once the container is `running` the tool returns promptly with `health: null` and `met: false` (false = "not confirmed healthy", not "unhealthy" - check `health` to tell them apart). A container that exits before becoming healthy returns its terminal `status` and `met: false`. Log-match semantics: `pattern` is matched as a **plain substring** by default - safe against any input, including adversarial ones. Pass `regex=True` to match `pattern` as a regular expression (via `re.search`) instead; only do this with patterns you trust, since a regex with catastrophic backtracking run against attacker-influenced log content can exhaust CPU (ReDoS). Checks stdout and stderr, most recent lines first within each poll. If the container exits/dies before the pattern ever appears, returns promptly with `met=false` (not `timed_out`) - no further logs can arrive, so there's nothing to keep polling for. Args: until: Condition to wait for: "not-running" (default), "next-exit", "removed", "healthy", or "log-match" (requires `pattern`) timeout_seconds: Max seconds to wait before returning with timed_out=true poll_interval: "healthy"/"log-match" only: seconds between re-checks (default 2, > 0); capped by the time left so a large value can't push the total wait past the timeout…
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
| pattern | string | – | – |
| poll_interval | number | – | – |
| regex | boolean | – | – |
| timeout_seconds | number | – | – |
| until | string | – | – |
No output schema declared.
No examples provided.
context_create ~377
Create a new Docker CLI context pointing at a daemon endpoint. Registers a named endpoint for the CLI; switch with `context_use`, enumerate with `context_list`. It does not retarget this server's docker-py client (pinned at startup). Does not raise on a non-zero CLI exit (a missing `docker` binary or a timeout still raises) - inspect `returncode`/`stderr` in the result. It does raise ToolInputError before running anything if `docker_host` or a TLS path contains a comma, which would inject extra keys (including `skip-tls-verify`) into the endpoint spec. Args: name: Name for the new context (must not already exist) docker_host: Daemon URL, e.g. "tcp://10.0.0.5:2376" or "unix:///var/run/docker.sock"; no commas description: Human description shown in `context ls` tls_ca: Path on the local host to the CA cert (for TLS daemons); no commas tls_cert: Path on the local host to the client cert; no commas tls_key: Path on the local host to the client key; no commas skip_tls_verify: Disable TLS verification (insecure; for testing only). The only way to set it: it cannot be smuggled through `docker_host` Returns: dict: {"returncode": int, "stdout": str, "stderr": str, "truncated": bool}
| Name | Type | Req | Description |
|---|---|---|---|
| description | string | – | – |
| docker_host | string | yes | – |
| name | string | yes | – |
| skip_tls_verify | boolean | – | – |
| tls_ca | string | – | – |
| tls_cert | string | – | – |
| tls_key | string | – | – |
No output schema declared.
No examples provided.
context_inspect ~106
Return the full configuration for a single Docker context. Full endpoint/TLS detail for one context; `context_list` gives the one-line summary of all. Raises RemoteFailureError if the CLI call fails. Args: name: Context name (use the `Name` field from `context_list`) Returns: dict: The parsed `docker context inspect` entry (keys include "Name" and "Endpoints" with the daemon URL)
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | – |
No output schema declared.
No examples provided.
context_list ~156
List Docker CLI contexts known to the host running this MCP server. Contexts are a CLI concept (stored in the docker config dir) letting one CLI target multiple daemons. This server uses whatever DOCKER_HOST / current-context resolved to at startup, so changing contexts only affects future subprocess-based tools, not the docker-py SDK client. Use `context_inspect` for one context's full config and `context_use` to switch. Raises RemoteFailureError if the CLI call fails. Returns: list: One dict per context, keyed as the CLI emits them - `Name`, `Description`, `DockerEndpoint` and `Current`, the last being true for the context the CLI would use by default
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
context_remove ~149
Remove a Docker CLI context. Deletes only the CLI's connection metadata - the daemon it pointed at is untouched. The current context needs force=True (or `context_use` another first). Does not raise on a non-zero CLI exit (a missing `docker` binary or a timeout still raises) - inspect `returncode`/`stderr` in the result. Args: name: Context name to remove force: Force removal even if the context is the current one Returns: dict: {"returncode": int, "stdout": str, "stderr": str, "truncated": bool}
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | – | – |
| name | string | yes | – |
No output schema declared.
No examples provided.
context_use ~173
Set the active Docker context for the CLI on the host running this MCP server. Note: this does not retarget the long-lived docker-py client - SDK-backed tools keep using the endpoint they connected to at startup. To retarget those, restart the server with a different DOCKER_HOST / DOCKER_CONTEXT. Create contexts with `context_create`; list them with `context_list`. Does not raise on a non-zero CLI exit (a missing `docker` binary or a timeout still raises) - inspect `returncode`/`stderr` in the result. Args: name: Existing context name to set as default Returns: dict: {"returncode": int, "stdout": str, "stderr": str, "truncated": bool}
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | – |
No output schema declared.
No examples provided.
docs_lookup ~285
Look up Docker SDK/CLI/registry reference documentation by section. A tool-callable mirror of the docker-docs:// resources, for clients that can't read MCP resources (e.g. Claude Desktop, Cursor). Always registered regardless of DOCKER_MCP_SERVER_DISABLE - looking something up costs nothing and isn't tied to any single Docker feature area - but an individual section still refuses if the domain it documents is disabled, matching the equivalent `docker-docs://{section}` resource exactly. Omit `section` to list every available section with its source URL (same as `docker-docs://contents`); pass a `section` name to fetch that page's content (same as `docker-docs://{section}`). Most useful before constructing an `extra_kwargs`-style passthrough dict for a tool like `container_run`/`container_create`/`service_create` (their docstrings only list common keys, not every key docker-py accepts), or before writing Compose/Dockerfile/buildx bake-file syntax, which no tool generates. Args: section: Section name (from a no-argument call's index); omit to list all sections instead Returns: str: JSON section index (no `section`) or that section's raw HTML/Markdown content
| Name | Type | Req | Description |
|---|---|---|---|
| section | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
host_list ~174
List the Docker hosts configured via DOCKER_MCP_SERVER_HOSTS. With a single host (or the var unset) this is the one resolved daemon; with several it is the set that the `host` argument selects from. The `default` entry is the one used when `host` is omitted; pass a `name` as the `host` argument of daemon-backed tools (`system_ping(host=...)` checks one entry). The `docker-mcp://hosts` resource mirrors this tool. Returns: list[dict]: one per host: name; url (resolved daemon URL, null = docker-py platform default); read_only; non_destructive (blocks destructive calls only); tls (whether a per-host cert dir is configured); default (the omitted-host fallback)
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
hub_rate_limit ~229
Report the caller's remaining Docker Hub pull-rate-limit budget. Sends a HEAD to the `ratelimitpreview/test` manifest (a HEAD isn't metered as a pull, so the check costs no budget) and reads the RateLimit-Limit / RateLimit-Remaining headers. Call it before a large `compose_pull` / `image_pull` to avoid hitting the cap mid-deploy. Credentials raise the limit and switch metering from per-IP to per-account; falls back to DOCKER_MCP_SERVER_REGISTRY_USERNAME / DOCKER_MCP_SERVER_REGISTRY_PASSWORD, does NOT read `~/.docker/config.json`. Plans with no limit return no headers - reported as `"unlimited": true`. Args: username: Hub username (overrides DOCKER_MCP_SERVER_REGISTRY_USERNAME) password: Hub password/token (overrides DOCKER_MCP_SERVER_REGISTRY_PASSWORD) Returns: dict: {"authenticated", "limit", "remaining", "window_seconds", "unlimited"}
| Name | Type | Req | Description |
|---|---|---|---|
| password | string | – | – |
| username | string | – | – |
No output schema declared.
No examples provided.
hub_repo_info ~141
Fetch Docker Hub metadata for a repository. Public repos only: sends no auth and does NOT read the local Docker credential store; private repos return 404/401. Hub-only metadata (stars, pulls, description) - use `registry_tags` for tag lists on any OCI registry and `hub_tags` for Hub tag details. Args: repository: Hub repository, e.g. "library/alpine" or "myorg/myimage" Returns: dict: The Hub /v2/repositories/<repo>/ response (description, star_count, pull_count, last_updated, is_private, etc.)
| Name | Type | Req | Description |
|---|---|---|---|
| repository | string | yes | – |
No output schema declared.
No examples provided.
hub_tags ~191
List tags on a Docker Hub repository with Hub-specific metadata. Hits the Hub UI API (hub.docker.com) for richer per-tag data than `registry_tags` - last pushed date, per-platform sizes, digest. Public repos only: sends no auth and does NOT read `~/.docker/config.json`; private repos return 404/401 (use `registry_tags` against registry-1.docker.io with credentials). Args: repository: Hub repository, e.g. "library/alpine" or "myorg/myimage" limit: Max tags to return (default 100, >= 1); pagination capped at 50 pages Returns: dict: {"name": <repo>, "tags": [{name, full_size, last_updated, digest, images}, ...], "truncated": bool}
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| repository | string | yes | – |
No output schema declared.
No examples provided.
image_build ~786
Build an image from a Dockerfile using the daemon's classic builder. Use this for simple single-platform builds from a local context. For multi-platform builds, BuildKit cache export/import, or advanced build features prefer `buildx_build`. `path` must be a directory accessible on the host running this server (it is the build context sent to the daemon). `dockerfile` is normally relative to `path`; omit to use the default `Dockerfile`. `dockerfile` is not confined to the context, despite the usual relative form: docker-py detects an absolute path, or a relative one escaping via `..`, reads that file from the **server host's** filesystem and injects its contents into the build. So it can read any file the server user can, like the other host-filesystem parameters (`dest_path`, `from_file`), and unlike them it is easy to mistake for a context-relative name. `buildx_build`'s `--file` resolves differently again (against the CLI's working directory) - see its docstring. Args: path: Build context directory path on the server host tag: Name and optional tag in "name:tag" format to apply to the built image quiet: Suppress verbose build output (final image id still returned) nocache: Ignore the layer cache and rebuild all layers rm: Remove intermediate containers on success pull: Always pull a newer version of each FROM base image before building forcerm: Remove intermediate containers even on build failure dockerfile: Dockerfile filename relative to path (default: "Dockerfile"); an absolute path or one containing ".." reads that file from the server host instead of the context buildargs: Build-time variables passed as `--build-arg`; dict of str to str container_limits: Resource limits for the build container, e.g. {"memory": 134217728} shmsize: Size of /dev/shm in bytes for build steps that need shared memory labels: Labels to set on the resulting image (dict of str to str) cache_from: List of image references…
| Name | Type | Req | Description |
|---|---|---|---|
| buildargs | object | – | – |
| cache_from | array | – | – |
| container_limits | object | – | – |
| dockerfile | string | – | – |
| extra_hosts | object | – | – |
| forcerm | boolean | – | – |
| isolation | string | – | – |
| labels | object | – | – |
| network_mode | string | – | – |
| nocache | boolean | – | – |
| path | string | – | – |
| platform | string | – | – |
| pull | boolean | – | – |
| quiet | boolean | – | – |
| rm | boolean | – | – |
| shmsize | integer | – | – |
| squash | boolean | – | – |
| tag | string | – | – |
| target | string | – | – |
| use_config_proxy | boolean | – | – |
No output schema declared.
No examples provided.
image_history ~146
Return the layer history of an image. Useful for auditing what commands built each layer and diagnosing image size. Each entry includes `Id` (layer digest or "<missing>" for imported layers), `Created` (unix timestamp), `CreatedBy` (the Dockerfile command that produced the layer, e.g. a RUN or COPY), `Size` (bytes added by that layer), and `Comment`. For full image metadata use `image_inspect` instead. Args: id_or_name: Image name (with optional tag/digest) or id Returns: list: Layer history entries, newest first
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
No output schema declared.
No examples provided.
image_import ~813
Create an image from a flat root-filesystem tarball, like `docker import`. Imports a *filesystem* archive as a new single-layer image with no build history - not the same thing as `image_load`, which restores a `docker save` archive complete with its layers, tags and history, so prefer `image_load` for anything `image_save` produced. Use this for a rootfs that came from somewhere else: a `container_export` archive, a distro base tarball, a VM image dump. The result has an empty config - no `CMD`/`ENTRYPOINT`/`ENV` - unless you supply `changes`, so an imported image is usually not runnable until you set at least a command. Pass exactly one source (`from_file`, `data`, `from_url` or `from_image`); ToolInputError otherwise. `from_url` and `from_image` are fetched by the *daemon*, `from_file`/`data` are read here and uploaded; a `from_file` path that is not a readable file raises rather than being retried as a URL. Unlike the other image-creating tools this stamps no provenance labels: the Engine's import call accepts no labels field, and `changes` does not cover `LABEL`. Args: repository: Repository name to give the new image, e.g. "myorg/rootfs"; may include a tag (`myorg/rootfs:v1`), and defaults to `:latest` when it does not. Omit to import untagged, addressable only by the id in the returned progress (omit it entirely -- a blank string is a ToolInputError, not a shorthand for untagged). A digest reference is refused by the daemon. Required if `tag` is given tag: Tag to apply, e.g. "v1". **Overrides** a tag already in `repository` rather than being ignored, so passing `repository="myorg/rootfs:v1"` with `tag="v2"` yields `:v2`. Requires `repository` (ToolInputError without it - the daemon would otherwise silently drop the tag and import untagged). Blank is also a ToolInputError, not a shorthand for the default: the daemon would substitute `latest` without saying so from_file: Path to a rootfs tarball on…
| Name | Type | Req | Description |
|---|---|---|---|
| changes | array | – | – |
| data | string | – | – |
| from_file | string | – | – |
| from_image | string | – | – |
| from_url | string | – | – |
| repository | string | – | – |
| tag | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
image_inspect ~175
Return the full inspect detail for a single local image. Includes config (env, entrypoint, exposed ports), size, layer digests (`RootFS.Layers`), and all tags/digests referencing it (`RepoTags`/`RepoDigests`). For a quick overview of many images use `image_list` instead. For the per-layer build history (which command produced each layer) use `image_history`. Only inspects images already present locally - for a remote image's manifest without pulling it use `image_registry_data` or `registry_manifest`. Args: id_or_name: Image name (with optional tag/digest) or id Returns: dict: Full image inspect attrs (equivalent to `docker inspect` on an image)
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
No output schema declared.
No examples provided.
image_list ~174
List images in the daemon's local store. Local only - for a registry's contents use `registry_tags` / `hub_tags`, and `image_search` to find images on Docker Hub. Dangling (untagged) build leftovers show with filters={"dangling": True}. Args: repository: Only show images of this repository all: Show intermediate image layers filters: Filter by attributes (label, dangling, before, since, etc.) Returns: list: One summary dict per image ({"Id", "RepoTags", "RepoDigests", "Created", "Size", "Labels", ...}); use `image_inspect` for a full inspect payload
| Name | Type | Req | Description |
|---|---|---|---|
| all | boolean | – | – |
| filters | object | – | – |
| repository | string | – | – |
No output schema declared.
No examples provided.
image_load ~223
Load an image from a tarball produced by `image_save`, from in-band bytes or a file on the server host. Counterpart of `image_save`; when the image lives in a registry, `image_pull` is the normal route, and for a flat rootfs archive that is not a `docker save` bundle use `image_import`. Pass exactly one of `data` (tarball bytes in band) or `from_file` (a path on the server host, streamed straight to the daemon - preferred for anything but small images, since in-band bytes are base64-encoded by MCP). `from_file` is read by the server's user; `~` is expanded. Args: data: Tarball contents; exactly one of data/from_file from_file: Path to a tarball produced by `docker save` / `image_save`; exactly one of data/from_file Returns: list: One full inspect payload per loaded image
| Name | Type | Req | Description |
|---|---|---|---|
| data | string | – | – |
| from_file | string | – | – |
No output schema declared.
No examples provided.
image_prune ~168
Remove unused local images to reclaim disk space. Without filters removes only "dangling" images - untagged layers not referenced by any tag or container. To remove all images not used by any container (including tagged ones) pass `filters={"dangling": False}`. Valid filter keys: `dangling` (bool as string "true"/"false"), `until` (RFC3339 timestamp or duration like "24h"), `label` (key or key=value). Use `system_df` first to see how much space is reclaimable. Args: filters: Narrow which images to remove; omit to remove dangling images only Returns: dict: {"ImagesDeleted": [...], "SpaceReclaimed": <bytes>}
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | – | – |
No output schema declared.
No examples provided.
image_prune_builds ~355
Delete the daemon's build cache to reclaim disk space. Prunes the *build cache* - a separate Engine resource from the images `image_prune` removes, so run both to reclaim everything a build leaves behind. Prefer `buildx_prune` when the build ran on a non-default buildx builder (that builder keeps its own cache, invisible here) or when you need any disk ceiling at all - `reserved_space`, `max_used_space` or `min_free_space`, none of which the docker-py path can send; this tool needs no CLI plugin and works over any transport, including a daemon with no local `docker` binary. Inventory first with `system_df` (its `BuildCache` entry) or `buildx_du`. Destructive and immediate: later builds must re-run the steps whose cache was removed. Needs Docker API v1.31+; passing either `filters` or `all` needs v1.39+ and raises `InvalidVersion` on an older daemon - omit both to prune with the daemon's own defaults. Args: filters: Narrow which cache records to remove, e.g. {"until": "24h"} (a duration or timestamp relative to the daemon's clock); also accepts `id`, `parent`, `type`, `description`, `inuse`, `shared`, `private`; omit to let the daemon prune unused cache all: Remove all types of build cache, not just the unused records Returns: dict: {"CachesDeleted": [...], "SpaceReclaimed": <bytes>}
| Name | Type | Req | Description |
|---|---|---|---|
| all | boolean | – | – |
| filters | object | – | – |
No output schema declared.
No examples provided.
image_pull ~263
Pull an image from a registry to the daemon's local store. Private repositories need credentials - `system_login` (or `docker login` on the host) first, or `auth_config` to authenticate this call alone. Use `image_load` for tarballs, and `registry_manifest` / `image_registry_data` to inspect a remote image without pulling it. Security: `auth_config` carries registry credentials, which many MCP clients log verbatim. Prefer `docker login` on the host so the `docker` module reuses credentials cached in `~/.docker/config.json`, and leave `auth_config` unset. Args: tag: The image tag (ignored when all_tags=True) all_tags: Pull all tags from the repository platform: Platform in os/arch format auth_config: Per-call registry credentials under the keys `username` and `password`; overrides the cached credential for this pull only Returns: dict | list: The pulled image's full inspect payload, or one per image if all_tags=True
| Name | Type | Req | Description |
|---|---|---|---|
| all_tags | boolean | – | – |
| auth_config | object | – | – |
| platform | string | – | – |
| repository | string | yes | – |
| tag | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
image_push ~170
Push an image or repository to a registry. The local image must already bear the target name - `image_tag` it with the registry-qualified `repository[:tag]` first; a bare name pushes to Docker Hub. Private registries need credentials (`system_login`, or `docker login` on the host). Security: `auth_config` carries registry credentials, which many MCP clients log verbatim. Prefer `docker login` on the host so the `docker` module reuses credentials cached in `~/.docker/config.json`, and leave `auth_config` unset. Args: auth_config: Registry authentication config Returns: str: Push output as a string
| Name | Type | Req | Description |
|---|---|---|---|
| auth_config | object | – | – |
| repository | string | yes | – |
| tag | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
image_registry_data ~172
Get registry data for an image without pulling it, via the daemon's distribution endpoint. Uses the daemon (and its cached credentials) to resolve the remote descriptor and platform list. For direct registry access without a daemon use `registry_manifest`. Security: `auth_config` carries registry credentials, which many MCP clients log verbatim. Prefer `docker login` on the host so the `docker` module reuses credentials cached in `~/.docker/config.json`, and leave `auth_config` unset. Args: repository: Image reference auth_config: Registry authentication config Returns: dict: The registry data document {"Descriptor", "Platforms"} - the OCI descriptor and the platforms available for the reference
| Name | Type | Req | Description |
|---|---|---|---|
| auth_config | object | – | – |
| repository | string | yes | – |
No output schema declared.
No examples provided.
image_remove ~182
Remove a local image by name or id. Fails without `force` if the image is tagged by multiple names (untag first with `image_tag`) or if stopped containers reference it. Running containers always block removal regardless of `force`. `noprune` keeps untagged parent layers that would otherwise be removed as a side-effect; leave False unless you need to preserve the parent layers for another purpose. Args: id_or_name: Image name (with optional tag/digest) or id to remove force: Remove even if referenced by stopped containers or multiple tags noprune: Do not delete untagged intermediate parent layers Returns: bool: True after removal completes
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | – | – |
| id_or_name | string | yes | – |
| noprune | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | – |
No examples provided.
image_save ~310
Save an image as a tar archive: to a file on the server host, or in band. The archive keeps layers, tags, and metadata so `image_load` can restore it - different from `container_export`, which flattens one container's filesystem. With `dest_path` the archive streams straight to disk (no byte cap), so it handles large images - the file is written by the server's user, `~` is expanded, and an existing file is refused unless `overwrite=True`. Without `dest_path` the tar bytes are returned in band, capped at `max_bytes` (default 32 MiB) because MCP base64-encodes them - a fallback for when no writable host path exists (e.g. a containerized server without a bind mount). Args: dest_path: Destination path on the server host; omit to return the bytes in band named: Whether to retain repository/tag names in the saved archive overwrite: Replace dest_path if it already exists max_bytes: In-band mode: abort with ToolInputError beyond this many bytes (default 32 MiB) Returns: bytes | dict: the tarball bytes (in band), or {"path": <resolved path>, "bytes_written": int}
| Name | Type | Req | Description |
|---|---|---|---|
| dest_path | string | – | – |
| id_or_name | string | yes | – |
| max_bytes | integer | – | – |
| named | boolean | – | – |
| overwrite | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
image_search ~171
Search Docker Hub for public images matching a term. Searches Docker Hub only - not GHCR, ECR, or other registries. For listing tags on a specific image from any OCI registry use `registry_tags` instead. Args: term: Search keyword, e.g. "nginx" or "python" limit: Maximum number of results to return (Docker Hub default is 25) Returns: list: Result dicts: {"name", "description", "star_count", "is_official", "is_automated"} - `is_automated` is deprecated in the Engine API and is always false, so rank on `star_count`/`is_official` instead
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| term | string | yes | – |
No output schema declared.
No examples provided.
image_tag ~174
Tag an image into a repository (add a name to an existing local image). The image id stays the same and no data is copied - a tag is an alias. Typical flow: tag with the registry-qualified name, then `image_push`. `image_remove` on a tag merely untags while other names remain. Tagging over a name that already exists repoints it, without asking. Args: id_or_name: The source image name or id repository: Target repository name (registry-qualified for pushing, e.g. "ghcr.io/o/r") tag: Tag for the new image (default "latest") Returns: bool: True if the image was tagged
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
| repository | string | yes | – |
| tag | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | – |
No examples provided.
network_connect ~348
Attach a running container to an additional network without restarting it. Use this to give a container access to services on a network it was not started with. `aliases` sets extra DNS names for this container within the network (other containers can reach it by those names in addition to its container name). `ipv4_address` / `ipv6_address` assign a specific IP on the network; omit to let the driver assign one. `links` is a legacy feature (deprecated; prefer DNS aliases). Use `network_disconnect` to undo. Args: id_or_name: Network id or name to connect the container to container: Container id or name to attach aliases: Additional DNS names for this container within the network links: Legacy container links (deprecated) ipv4_address: Static IPv4 address to assign on this network ipv6_address: Static IPv6 address to assign on this network link_local_ips: Link-local IP addresses to assign driver_opt: Driver-specific endpoint options mac_address: Static MAC address for this endpoint, e.g. "02:42:ac:11:00:04"; per-network rather than per-container, and a driver is free to ignore it Returns: bool: True after the container is connected
| Name | Type | Req | Description |
|---|---|---|---|
| aliases | array | – | – |
| container | string | yes | – |
| driver_opt | object | – | – |
| id_or_name | string | yes | – |
| ipv4_address | string | – | – |
| ipv6_address | string | – | – |
| link_local_ips | array | – | – |
| links | array | – | – |
| mac_address | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | – |
No examples provided.
network_create ~312
Create a network. The daemon default driver is `bridge` (single-host); use `overlay` for swarm-wide networks. Creating a network attaches nothing - connect containers afterwards with `network_connect` or at start via `container_run(network=...)`. Created networks carry provenance labels. A duplicate `name` is always rejected, so creating is not idempotent - check `network_list` first when the network may already exist. Args: driver: Driver name (daemon default `bridge`; `overlay` for swarm scope) options: Driver-specific options dict ipam: IPAM configuration as a dict (engine shape: {"Driver", "Config": [{"Subnet", "Gateway", ...}]}) internal: Restrict external access labels: Labels to set on the network enable_ipv6: Enable IPv6 networking attachable: Allow standalone containers to attach (swarm overlay networks) scope: Network scope; the driver picks a sensible default when omitted ingress: Make this an ingress network for swarm routing-mesh Returns: dict: The created network's full inspect payload
| Name | Type | Req | Description |
|---|---|---|---|
| attachable | boolean | – | – |
| driver | string | – | – |
| enable_ipv6 | boolean | – | – |
| ingress | boolean | – | – |
| internal | boolean | – | – |
| ipam | object | – | – |
| labels | object | – | – |
| name | string | yes | – |
| options | object | – | – |
| scope | string | – | – |
No output schema declared.
No examples provided.
network_disconnect ~127
Disconnect a container from a network. The container keeps running with its other network attachments; only this endpoint is removed (the reverse of `network_connect`). A network with connected containers cannot be deleted, so disconnect them before `network_remove`. Args: container: The container id or name to disconnect force: Force the disconnect; use to clear a stale endpoint (e.g. from a deleted container) Returns: bool: True after the container is disconnected
| Name | Type | Req | Description |
|---|---|---|---|
| container | string | yes | – |
| force | boolean | – | – |
| id_or_name | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | – |
No examples provided.
network_inspect ~115
Return the full inspect detail for a single network. Includes the connected containers (`Containers`, keyed by container id, with each entry's assigned IP), IPAM config, and driver options. For a quick overview of many networks use `network_list` instead - its default (non-`greedy`) response omits the per-network `Containers` detail for speed. Returns: dict: Full network inspect attrs (equivalent to `docker network inspect`)
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
No output schema declared.
No examples provided.
network_list ~280
List networks. Valid filter keys: `driver` (driver name), `label` (key or key=value), `type` ("custom" or "builtin"). `names`/`ids` are a separate shorthand for filtering by exact name/id, applied in addition to `filters`. Set `greedy` to fetch each network's attrs individually (adds the connected-containers detail that `network_inspect` returns, at the cost of one extra daemon call per network) - leave it False for a fast summary list. Args: names: Filter by exact network names ids: Filter by exact network ids filters: Additional server-side filters; see description for valid keys greedy: Fetch extended per-network details (including connected containers) managed_only: Only return networks created by this MCP server (filters on the docker-mcp-server.managed label); combines with any `filters` given Returns: list: One dict ({"Id", "Name", "Driver", "Scope", ...}) per network: summary attrs by default, full inspect attrs (adding "Containers") when greedy=True
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | – | – |
| greedy | boolean | – | – |
| ids | array | – | – |
| managed_only | boolean | – | – |
| names | array | – | – |
No output schema declared.
No examples provided.
network_prune ~125
Remove networks that have no active container endpoints. Built-in networks (bridge, host, none) are never removed. Only networks with zero connected containers are eligible. Valid filter keys: `until` (RFC3339 timestamp or duration - removes networks created before that point), `label` (key or key=value). Use `network_remove` to delete one specific network instead. Args: filters: Narrow which networks to remove; omit to remove all unused custom networks Returns: dict: {"NetworksDeleted": [...]}
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | – | – |
No output schema declared.
No examples provided.
network_remove ~103
Remove a single custom network by id or name. Fails if any container is still attached (disconnect with `network_disconnect` or stop the containers first). Built-in networks (`bridge`, `host`, `none`) can never be removed and return an error regardless of attachment state. For bulk cleanup of every unused custom network at once use `network_prune` instead. Returns: bool: True after removal
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | – |
No examples provided.
node_inspect ~126
Get a swarm node's full inspect payload by id or name. Must run against a swarm manager. Shows role, availability, status, and manager reachability - use `node_list` to enumerate nodes first; `service_ps(filters={"node": ...})` shows what a service runs on one node. Args: id_or_name: The node id or hostname (as shown by `node_list`) Returns: dict: The node's full document (Spec{Role, Availability}, Status, ManagerStatus for managers)
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
No output schema declared.
No examples provided.
node_list ~87
List swarm nodes. Must run against a swarm manager. The fleet view of membership, role, and state; drill into one node with `node_inspect`. Args: filters: Filter by attributes (id, name, membership, role) Returns: list: One full node document per node (Spec, Status, ManagerStatus for managers)
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | – | – |
No output schema declared.
No examples provided.
node_remove ~115
Remove a node from the swarm. A node should normally be drained (`node_update` with Availability "drain") and have left the swarm first, so its tasks reschedule cleanly. Removing an active/reachable node requires `force=True`. Args: id_or_name: The node id or name to remove force: Force removal of an active/reachable node Returns: bool: True after the node is removed
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | – | – |
| id_or_name | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | – |
No examples provided.
node_update ~140
Replace a node's spec (availability, name, role, labels). Replacement, not a merge: `spec` becomes the node's entire spec, and omitted keys are cleared. Fetch the current spec via `node_inspect` (its `Spec` key), modify it, and resubmit the whole dict - e.g. sending just {"Availability": "drain"} would also wipe the node's role and labels. Args: spec: The complete new node spec (see description - omitted keys are cleared) Returns: bool: True after the update
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | – |
| spec | object | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | – |
No examples provided.
What is the Docker MCP Server server?
Docker MCP Server is listed in the public MCP registry as io.github.L337-org/docker-mcp-server. Manage Docker (containers, images, Compose, Swarm, registries) via the Docker SDK and CLI. This page covers its container image (ghcr.io/l337-org/docker-mcp-server:2.2.6).
Is the Docker MCP Server server safe to use?
Docker MCP Server scores 41 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Docker MCP Server server expose?
Docker MCP Server exposes 165 tools: buildx_build, buildx_bake, buildx_imagetools_inspect, buildx_imagetools_create, buildx_list, and 160 more. Their descriptions and schemas cost roughly 39,062 tokens of context every time the server is loaded.
Is the Docker MCP Server server still maintained?
Docker MCP Server is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.