Docker MCP Server
OCI · GHCR.IO/L337-ORG/DOCKER-MCP-SERVER:2.2.2 · 3 COMPONENTS · SCANNED AUG 3
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 →
Supply Chain Security0
- Malware scan not yet available for this package.Unverified
- CVE data not yet available for this package.Unverified
- Install-script risk not yet assessed.Unverified
- Dependency-health data not yet available.Unverified
Provenance & Transparency32
- 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 2 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability72
- 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 35053 tokens (~216/item across 162 items; 156 tools + 6 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 Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
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
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
Unverified: 2 categories
Categories scored 0 because we could not verify them: 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.
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
oci · ghcr.io/l337-org/docker-mcp-server:2.2.2
claude mcp add l337-org-docker-mcp-server -- docker run --rm -i ghcr.io/l337-org/docker-mcp-server:2.2.2
codex mcp add l337-org-docker-mcp-server -- docker run --rm -i ghcr.io/l337-org/docker-mcp-server:2.2.2
{
"$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.2"
],
"enabled": true
}
}
} mcp_servers:
l337-org-docker-mcp-server:
command: "docker"
args: ["run", "--rm", "-i", "ghcr.io/l337-org/docker-mcp-server:2.2.2"] {
"mcpServers": {
"l337-org-docker-mcp-server": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"ghcr.io/l337-org/docker-mcp-server:2.2.2"
]
}
}
} 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.
- 1 Aug 26 +27
- Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window). security
- MCP protocol: unverified → pass ▲ functional
- Schema quality: unverified → 100 ▲ functional
- Tool coverage: unverified → 100 ▲ functional
- First check of Schema quality: good functional
- First check of Schema quality: fail functional
- First check of Tool coverage: 0 functional
- First check of Tool coverage: 23 functional
- First check of Schema quality: fail functional
- 31 Jul 26 6
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 3 Aug 2026 · Analysed oci/ghcr.io/l337-org/docker-mcp-server:2.2.2
Provenance none
Ecosystem: oci · Outcome: none
Reason: no_attestation
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.
plugin_disable ~144
Disable a plugin so it stops intercepting Docker API calls; the plugin remains installed. A disabled plugin cannot be used by new containers but existing containers that already have it attached are unaffected. Use `force=True` to disable even if active containers are still using it — this may cause those containers to lose access to plugin-provided resources (e.g. a volume driver). Re-enable with `plugin_enable`. args: name - The plugin name force - Disable even if active containers are using the plugin (may disrupt them) returns: bool - True after the plugin is disabled
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | — | — |
| name | string | yes | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
plugin_enable ~151
Activate an installed plugin so Docker routes relevant API calls through it. Activates a plugin that is currently disabled — either freshly installed or previously disabled via `plugin_disable`. If the plugin exposes configuration (check via `plugin_inspect`), call `plugin_configure` while it is still disabled before enabling it. `timeout_seconds` controls how long Docker waits for the plugin process to become healthy; 0 means wait indefinitely. args: name - The plugin name to enable timeout_seconds - Seconds to wait for the plugin to become healthy (0 = no timeout) returns: bool - True after the plugin is enabled
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | — |
| timeout_seconds | integer | — | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
plugin_inspect ~118
Return the full attrs for a single installed plugin. Use this to check a plugin's `Enabled` state before calling `plugin_enable` / `plugin_disable`, or to read the config keys it exposes under `Settings.Env` before calling `plugin_configure`. For the set of all installed plugins use `plugin_list`. args: name - Plugin name, e.g. "vieux/sshfs:latest" returns: dict - The plugin's attrs, including `Enabled` and `Settings`
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | — |
No output schema declared.
No examples provided.
plugin_install ~196
Install a plugin from Docker Hub. `remote` is a Docker Hub reference in `author/name:tag` form, e.g. `vieux/sshfs:latest`. The daemon handles permission grants non-interactively. After installation use `plugin_inspect` to confirm the plugin's enabled state, then call `plugin_enable` to activate it if needed, and optionally `plugin_configure` first if it requires settings. Use `plugin_list` to list all plugins, or `plugin_remove` to uninstall. args: remote - Docker Hub plugin reference, e.g. "vieux/sshfs:latest" local_name - Alias to refer to the plugin locally; defaults to remote returns: dict - The installed plugin's attrs ({"Id", "Name", "Enabled", "Settings", "Config"})
| Name | Type | Req | Description |
|---|---|---|---|
| local_name | string | — | — |
| remote | string | yes | — |
No output schema declared.
No examples provided.
plugin_list ~112
List installed engine plugins with their full attrs. Covers managed engine plugins (volume/network/logging drivers installed via `plugin_install`) — not docker CLI plugins such as compose, buildx, or scout. Use it to find exact plugin names for `plugin_inspect`/`plugin_enable`/`plugin_disable`/`plugin_remove`; the `Enabled` key shows each plugin's state. returns: list - One attrs dict per installed plugin (Id, Name, Enabled, Settings, Config)
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
plugin_remove ~114
Uninstall an engine plugin from the daemon. Permanent removal — to deactivate but keep a plugin installed use `plugin_disable` instead. An enabled plugin must be disabled first unless `force=True`. Plugin names come from `plugin_list`. args: name - The plugin name (e.g. "vieux/sshfs:latest") force - Remove even if the plugin is enabled (default False) returns: bool - True after removal
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | — | — |
| name | string | yes | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
plugin_upgrade ~159
Upgrade an installed plugin to a newer version. The plugin must be disabled first — call `plugin_disable` before this, then `plugin_enable` afterwards to bring it back up. `remote` lets you upgrade to a different reference (e.g. a newer tag) than the plugin's current name; omit it to re-pull the same reference. Existing settings and volumes created by the plugin persist across the upgrade. args: name - The plugin name to upgrade remote - Reference to upgrade to, e.g. "vieux/sshfs:next" (default: same as name) returns: bool - True after the upgrade completes
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | — |
| remote | string | — | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
registry_image_config ~292
Fetch and parse an image's config blob from a registry without pulling. Answers "what's inside this image?" — env vars, entrypoint/cmd, workdir, exposed ports, user, labels, layer history (what `registry_manifest` only points at via `config.digest`). Resolves in up to three hops: manifest -> (if multi-platform) the `platform` entry's manifest -> the config blob. args: repository - Image/repository ref, e.g. "ghcr.io/org/repo"; `:tag`/`@digest` is stripped — pass via `reference` reference - Tag or digest (default "latest") platform - Platform to select from a multi-platform image, "os/arch[/variant]" (default "linux/amd64"); ignored for single-platform images username - Optional registry username (overrides DOCKER_MCP_SERVER_REGISTRY_USERNAME) password - Optional registry password/token (overrides DOCKER_MCP_SERVER_REGISTRY_PASSWORD) returns: dict - {"name", "registry", "reference", "platform", "config_digest", "config": <parsed>}; `platform` is the selected platform (None if single-platform)
| Name | Type | Req | Description |
|---|---|---|---|
| password | string | — | — |
| platform | string | — | — |
| reference | string | — | — |
| repository | string | yes | — |
| username | string | — | — |
No output schema declared.
No examples provided.
registry_manifest ~240
Fetch a repository's manifest without pulling. May return a single-platform image manifest or a multi-platform manifest list / OCI image index, depending on what the registry serves for that tag. Talks HTTPS directly — no daemon or CLI needed. Alternatives for the same question: `buildx_imagetools_inspect` (uses the docker CLI and its credential store) and `image_registry_data` (asks the daemon). args: repository - Image/repository ref, e.g. "ghcr.io/org/repo"; `:tag`/`@digest` is stripped — pass via `reference` reference - Tag or digest (default "latest") username - Optional registry username (overrides DOCKER_MCP_SERVER_REGISTRY_USERNAME; no config.json) password - Optional registry password/token (overrides DOCKER_MCP_SERVER_REGISTRY_PASSWORD) returns: dict - {"name", "registry", "reference", "media_type", "digest", "manifest": <JSON body>}
| Name | Type | Req | Description |
|---|---|---|---|
| password | string | — | — |
| reference | string | — | — |
| repository | string | yes | — |
| username | string | — | — |
No output schema declared.
No examples provided.
registry_tag_wait ~428
Block until a specific tag appears in a repository (e.g. waiting for a CI push to land). Never raises on timeout — the result always carries `met` and `timed_out`. Polls `registry_tags` every `poll_interval`s and checks whether `tag` is in its result. Works against Docker Hub too (`registry_tags`' own scope covers it), so there is no separate Hub variant. Unlike every other wait tool, this has no `host` argument — registry tools talk HTTPS directly to the registry, not a Docker daemon. Caveat: `registry_tags` paginates up to 50 pages (or `limit` tags, whichever comes first); if `tag` would only appear beyond that window it is never found, even once it exists. Raise `limit` if you expect a very large tag list. args: repository - Image/repository ref, e.g. "alpine", "ghcr.io/org/repo"; any `:tag`/`@digest` is stripped tag - The exact tag name to wait for username - Optional registry username (overrides DOCKER_MCP_SERVER_REGISTRY_USERNAME) password - Optional registry password/token (overrides DOCKER_MCP_SERVER_REGISTRY_PASSWORD) limit - Max tags to scan per poll (default 1000, >= 1); forwarded to `registry_tags` timeout_seconds - Max seconds to wait before returning with timed_out=true (default 600) poll_interval - Seconds between re-checks (default 5, > 0); capped by the time left so a large value can't push the total wait past the timeout returns: dict - {"repository", "tag", "met", "timed_out", "waited_seconds"}
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | — | — |
| password | string | — | — |
| poll_interval | number | — | — |
| repository | string | yes | — |
| tag | string | yes | — |
| timeout_seconds | number | — | — |
| username | string | — | — |
No output schema declared.
No examples provided.
registry_tags ~292
List tags for a repository in an OCI v2 registry without pulling. Works against Docker Hub, GHCR, ECR, GAR, and any OCI-compliant registry; anonymous if no credentials are passed. Talks directly to the registry over HTTPS and does NOT read `~/.docker/config.json` — for private registries prefer the DOCKER_MCP_SERVER_REGISTRY_USERNAME / DOCKER_MCP_SERVER_REGISTRY_PASSWORD env vars (keeps secrets out of tool args, which clients often log). Fetch one tag's manifest with `registry_manifest`; `hub_tags` adds Hub-specific tag metadata (sizes, push dates). args: repository - Image/repository ref, e.g. "alpine", "ghcr.io/org/repo"; any `:tag`/`@digest` is stripped username - Optional registry username (overrides DOCKER_MCP_SERVER_REGISTRY_USERNAME) password - Optional registry password/token (overrides DOCKER_MCP_SERVER_REGISTRY_PASSWORD) limit - Max tags to return (default 1000, >= 1); pagination capped at 50 pages returns: dict - {"name": <repo>, "registry": <host>, "tags": [..], "truncated": bool}
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | — | — |
| password | string | — | — |
| repository | string | yes | — |
| username | string | — | — |
No output schema declared.
No examples provided.
scout_compare ~379
Compare two image references and report the CVE delta. Exactly one of `to`, `to_env`, or `to_latest=True` must be supplied to identify the comparison target. Use it after a rebuild to check the new image against the old (`scout_cves` scans a single image). Does not raise on a non-zero CLI exit (a missing scout plugin still raises) — inspect `raw.stderr`. Raises ValueError if `to` names a local directory/archive while the call has to run on a remote `ssh://` host (no local scout plugin): the file is not staged, so it would resolve against that host's filesystem instead. args: image - The new / candidate image reference to - Compare against this image reference, directory, or archive (a local directory/archive only when the CLI runs on this host — see above) to_env - Compare against an image associated with this Scout environment to_latest - Compare against the latest scan of `image` only_severity - Filter to severities ("critical", "high", "medium", "low", "unspecified") ignore_unchanged - Exclude unchanged packages from the diff format - Output format: "json" (default), "markdown", or "text" platform - Platform of the image to analyze returns: dict - {"format": <format>, "result": <parsed-json-or-raw-text>, "raw": <CliResult dict>}
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | — |
| ignore_unchanged | boolean | — | — |
| image | string | yes | — |
| only_severity | array | — | — |
| platform | string | — | — |
| to | string | — | — |
| to_env | string | — | — |
| to_latest | boolean | — | — |
No output schema declared.
No examples provided.
scout_cves ~328
List vulnerabilities (CVEs) in an image via Docker Scout. Anonymous scans work for public images; Hub policy enforcement and richer recommendations need `docker login` on the host that runs the CLI — this server's host, or the target `ssh://` host itself when no local scout plugin is installed. Start with `scout_quickview` for a per-severity summary; `scout_sbom` inventories packages without vulnerability matching. Does not raise on a non-zero CLI exit (a missing scout plugin still raises) — inspect `raw.stderr`. args: image - Image reference (a tag or a digest) only_fixed - Only report CVEs with a fixed version available only_severity - Filter to severities: "critical", "high", "medium", "low", "unspecified" ignore_base - Exclude CVEs introduced by the base image format - Output format: "json" (default; parsed into the return dict), "sarif", "spdx", "list", "markdown", or "text" platform - Platform of the image to analyze, e.g. "linux/amd64" returns: dict - {"format": <format>, "result": <parsed-json-or-raw-text>, "raw": <CliResult dict>}
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | — |
| ignore_base | boolean | — | — |
| image | string | yes | — |
| only_fixed | boolean | — | — |
| only_severity | array | — | — |
| platform | string | — | — |
No output schema declared.
No examples provided.
scout_quickview ~180
Render a compact summary of an image's CVE posture. The fastest triage step — counts per severity plus base-image status. Drill into individual findings with `scout_cves`; get upgrade suggestions with `scout_recommendations`. Does not raise on a non-zero CLI exit (a missing scout plugin still raises) — inspect `raw.stderr`. args: image - Image reference format - Output format: "json" (default) or "text" platform - Platform of the image to analyze, e.g. "linux/amd64" returns: dict - {"format": <format>, "result": <parsed-json-or-raw-text>, "raw": <CliResult dict>}
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | — |
| image | string | yes | — |
| platform | string | — | — |
No output schema declared.
No examples provided.
scout_recommendations ~270
Suggest base-image upgrades for an image. Computed against Docker Scout's catalog; generally needs `docker login` on the host that runs the CLI (the target `ssh://` host itself when no local scout plugin is installed) to return useful results for private or rarely-scanned base images. The natural follow-up to `scout_cves` when the fix is a newer base image. Does not raise on a non-zero CLI exit (a missing scout plugin still raises) — inspect `raw.stderr`. args: image - Image reference only_refresh - Only show "refresh" recommendations (same major/minor) only_update - Only show "update" recommendations (newer minor/major) tag - Restrict to suggestions matching this tag pattern format - Output format: "json" (default) or "text" platform - Platform of the image to analyze returns: dict - {"format": <format>, "result": <parsed-json-or-raw-text>, "raw": <CliResult dict>}
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | — |
| image | string | yes | — |
| only_refresh | boolean | — | — |
| only_update | boolean | — | — |
| platform | string | — | — |
| tag | string | — | — |
No output schema declared.
No examples provided.
scout_sbom ~272
Generate a Software Bill of Materials (SBOM) for an image. Package inventory only — `scout_cves` adds vulnerability matching on top. SBOMs can be large; captured stdout is subject to MAX_CLI_OUTPUT_BYTES and may be truncated for big images. If that's a concern, run `docker scout sbom -o file.json …` on the host and load the file separately. Does not raise on a non-zero CLI exit (a missing scout plugin still raises) — inspect `raw.stderr`. args: image - Image reference format - SBOM format: "spdx" (default, SPDX JSON), "cyclonedx" (CycloneDX JSON), "json" (Scout's native JSON), "list" (plain-text package list) platform - Platform of the image to analyze returns: dict - {"format", "result", "raw": <CliResult dict>}. `result` is a parsed dict when `format` is "spdx"/"cyclonedx"/"json" and stdout parses cleanly; for "list" or a parse failure it's the raw text.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | — |
| image | string | yes | — |
| platform | string | — | — |
No output schema declared.
No examples provided.
secret_create ~205
Create a swarm secret; requires a swarm manager. Write-once: the payload can never be read back through the API (`secret_inspect` returns metadata only) and cannot be changed later — to rotate, create a new secret and update the consuming services, keeping your own copy of the value. For non-sensitive data that should stay readable, use `config_create` instead. Created secrets are stamped with provenance labels. args: name - Name for the secret (unique within the swarm) data - The secret payload (max 500 KB; must be empty when driver is set) labels - Labels to set on the secret driver - Optional secret-driver config for values held in an external store returns: dict - The created secret's attrs (ID and Spec metadata; never the payload)
| Name | Type | Req | Description |
|---|---|---|---|
| data | string | yes | — |
| driver | object | — | — |
| labels | object | — | — |
| name | string | yes | — |
No output schema declared.
No examples provided.
secret_inspect ~159
Get a swarm secret's metadata by id or name; requires a swarm manager. The returned attrs never include the secret's actual data (`Spec.Data` is write-only — the daemon accepts it on `secret_create` but never returns it back, by design). Use this to check a secret's `CreatedAt`, `Labels`, or which driver created it, not to read its contents. To see which services reference it, inspect each service's spec via `service_inspect` (there is no server-side filter for "services using this secret"). args: id_or_name - The secret id or name returns: dict - The secret's attrs, excluding the actual secret data
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | — |
No output schema declared.
No examples provided.
secret_list ~102
List swarm secrets' metadata; requires a swarm manager. Like `secret_inspect`, results never include secret data, only metadata (name, id, labels, timestamps). Valid filter keys: `id`, `name`, `names`, `label` (key or key=value). args: filters - Narrow the list; omit to return every secret returns: list - A list of secret attrs dicts (data-free)
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | — | — |
No output schema declared.
No examples provided.
secret_remove ~123
Remove a Swarm secret; requires a swarm manager. Removing a secret does not immediately affect running service tasks — tasks that already have the secret mounted retain access until they are restarted or the service is updated. Use `service_list` and inspect each service's spec via `service_inspect` to identify services that mount the secret before removing it (service filters do not support filtering by secret reference). args: id_or_name - The secret id or name to remove returns: bool - True after removal
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
service_create ~307
Create a Swarm service; requires a swarm manager node. Use this instead of `container_run` when you need replicated or global scheduling, rolling updates, or automatic restart across the swarm. Common `extra_kwargs` keys: `name` (str), `env` (list of "KEY=VAL"), `mode` ({"Replicated": {"Replicas": N}} or {"Global": {}}), `networks` (list of network names/ids), `endpoint_spec` ({"Ports": [{"PublishedPort": 80, "TargetPort": 8080}]}), `labels` (dict), `restart_policy` ({"Condition": "on-failure", "MaxAttempts": 3}), `resources` ({"Limits": {"NanoCPUs": 500000000, "MemoryBytes": 134217728}}). For anything else docker-py's `ServiceCollection.create` accepts, call `docs_lookup(section="services")` rather than guessing a key name. args: image - Image to run service tasks from (e.g. "nginx:alpine") command - Override the image's default command; string or list of strings extra_kwargs - Additional docker-py ServiceCollection.create keyword arguments returns: dict - The created service's full document ({"ID", "Version", "Spec", ...})
| Name | Type | Req | Description |
|---|---|---|---|
| command | — | — | — |
| extra_kwargs | object | — | — |
| image | string | yes | — |
No output schema declared.
No examples provided.
service_inspect ~140
Get a swarm service by id or name. Must run against a swarm manager. Returns the desired-state spec and rollout status — for the actually-running tasks use `service_ps`, or the `service-tasks://{id_or_name}` resource for a computed rollout summary. args: id_or_name - The service id or name insert_defaults - Merge default values into the output returns: dict - The full service document ({"ID", "Version", "Spec", "Endpoint", ...}; "UpdateStatus" during a rolling update)
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | — |
| insert_defaults | boolean | — | — |
No output schema declared.
No examples provided.
service_list ~135
List swarm services. Must run against a swarm manager. One entry per service (the desired state); `service_ps` lists a service's tasks, and `stack_services` groups services by stack. args: filters - Filter by attributes (id, name, label, mode) managed_only - Only return services created by this MCP server (filters on the docker-mcp-server.managed label); combines with any `filters` given returns: list - One full service document ({"ID", "Spec", ...}) per service
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | — | — |
| managed_only | boolean | — | — |
No output schema declared.
No examples provided.
service_logs ~329
Get a bounded snapshot of a swarm service's logs (never follows). `follow` is intentionally not exposed: the stream is joined into one string before returning, so following would block forever and grow unbounded. Collection is capped at `max_bytes` (ValueError if exceeded) so a noisy service can't OOM the server. The default is a bounded `tail=200`; `tail="all"` returns the whole buffer, which can be huge on long-running services and exceed the agent's context — prefer an integer, or `since`, to constrain output. Logs aggregate across all the service's tasks — `container_logs` reads a single container, and the `service-logs://{id_or_name}` resource is the resource-flavored equivalent of this tool. args: id_or_name - The service id or name details - Show extra details stdout - Include stdout stderr - Include stderr since - Show logs since this Unix timestamp timestamps - Include timestamps tail - Number of lines from the end (default 200), or the literal "all" for everything max_bytes - Abort with ValueError if the buffered logs exceed this many bytes (default 32 MiB) returns: str - Decoded log output
| Name | Type | Req | Description |
|---|---|---|---|
| details | boolean | — | — |
| id_or_name | string | yes | — |
| max_bytes | integer | — | — |
| since | integer | — | — |
| stderr | boolean | — | — |
| stdout | boolean | — | — |
| tail | — | — | — |
| timestamps | boolean | — | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | — |
No examples provided.
service_ps ~192
List a swarm service's tasks (per-replica scheduling units), like `docker service ps`. Shows where replicas run and why they fail: each task carries `Status` (State/Message/ContainerStatus), `DesiredState`, `NodeID`, and `Slot`. Prefer this over `container_list` for services (tasks may run on other nodes), `stack_ps` for a whole stack, and the `service-tasks://{id_or_name}` resource for a computed rollout summary. Requires a swarm manager. args: id_or_name - The service id or name filters - Filter dict; keys: id, name, node, label, desired-state (running|shutdown|accepted) returns: list - Task dicts (ID, Slot, NodeID, Status, DesiredState, Spec)
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | — | — |
| id_or_name | string | yes | — |
No output schema declared.
No examples provided.
service_remove ~87
Stop and remove a swarm service. Requires a swarm manager. Deletes the service definition and shuts down its tasks — no confirmation, no undo. To stop work but keep the definition, `service_scale` to 0 replicas. args: id_or_name - The service id or name returns: bool - True after the service is removed
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
service_rollback ~154
Roll a swarm service back to its previous spec (the docker `service rollback` equivalent). Re-applies the service's `PreviousSpec` — the spec from before the most recent `service_update` / `service_scale`. Raises ValueError if the service has no PreviousSpec (it has never been updated, or was already rolled back). The high-level SDK exposes no rollback, so this reads the current version and previous spec via the low-level APIClient and submits them with the low-level `update_service` API call. args: id_or_name - The service id or name returns: dict - The daemon response (a dict with a "Warnings" key)
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | — |
No output schema declared.
No examples provided.
service_scale ~172
Set the desired replica count for a Replicated-mode swarm service. Only applies to services in `Replicated` mode; a `Global` service runs one task per eligible node and has no replica count to set. The swarm scheduler places or removes tasks asynchronously to converge on the new count — this call returns once the update is accepted, not once every task is running. Check progress with `service_ps` or `service_inspect`. For any other spec change (image, env, resources) use `service_update` instead. args: id_or_name - The service id or name replicas - The desired number of running task replicas returns: bool - True once the scale request is accepted
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | — |
| replicas | integer | yes | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
service_update ~180
Update a swarm service's configuration, or force a redeploy with no spec change. Pass exactly one of `updates` (fields to change, same parameters as `service_create`) or `force=True` (the `docker service update --force` equivalent: bumps the ForceUpdate counter so the service's tasks redeploy with an unchanged spec — e.g. to reschedule after a node change or re-pull a mutable tag). args: id_or_name - The service id or name updates - Fields to update on the service; exactly one of updates/force force - Redeploy the service without changing its spec; exactly one of updates/force returns: bool - True after the update
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | — | — |
| id_or_name | string | yes | — |
| updates | object | — | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
service_wait ~396
Block until a swarm service's tasks converge, or a rolling update finishes. One contract for both modes: never raises on timeout — the result always carries `met` and `timed_out`. "running" polls task state via the same task-counting logic as `service-tasks://{id_or_name}` (not the unconfirmed daemon `ServiceStatus` field) until running tasks reach the desired count (Replicated mode) or every returned task is running (Global mode, which has no fixed target). "update-converged" polls `UpdateStatus.State` until it reaches a terminal value (`completed` or `rollback_completed`); if the service has never been updated (no `UpdateStatus` at all), returns promptly with `met=false` — there's nothing to converge to, same as `container_wait`'s no-healthcheck case. args: id_or_name - The service id or name until - Condition to wait for: "running" (default) or "update-converged" replicas - "running" mode only: override the desired replica count (e.g. right after a same-turn `service_scale` call, before polling reflects the new target) timeout_seconds - Max seconds to wait before returning with timed_out=true (default 600) poll_interval - 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 returns: dict - {"service", "until", "met", "timed_out", "running_tasks", "desired_tasks", "failed_tasks", "update_state", "waited_seconds"}
| Name | Type | Req | Description |
|---|---|---|---|
| id_or_name | string | yes | — |
| poll_interval | number | — | — |
| replicas | integer | — | — |
| timeout_seconds | number | — | — |
| until | string | — | — |
No output schema declared.
No examples provided.
stack_deploy ~377
Deploy (or update) a stack to the swarm from one or more Compose files. Requires the target daemon to be a swarm manager. Re-running with the same `name` updates the stack in place. Defaults to `detach=True` (returns once specs are submitted, not on convergence); set `detach=False` to wait for the rollout (give it a generous `timeout_seconds`). The swarm analogue of `compose_up`; watch the rollout with `stack_services` / `stack_ps`. Does not raise on a non-zero CLI exit — inspect `returncode`/`stderr` in the result. args: name - Name of the stack to create or update compose_files - One or more Compose file paths (repeated `-c`; later override earlier). At least one required. with_registry_auth - Send registry credentials to swarm agents (needed for private images) prune - Remove services no longer defined in the Compose file resolve_image - Image-digest resolution: "always" (default), "changed", or "never" detach - Return immediately after submitting specs (True) vs wait for convergence (False) cwd - Working directory for resolving relative Compose paths (defaults to the server's cwd; copied to the target host if no local docker CLI) timeout_seconds - Subprocess timeout (default 1800s) returns: dict - {"returncode": int, "stdout": str, "stderr": str, "truncated": bool}
| Name | Type | Req | Description |
|---|---|---|---|
| compose_files | array | yes | — |
| cwd | string | — | — |
| detach | boolean | — | — |
| name | string | yes | — |
| prune | boolean | — | — |
| resolve_image | string | — | — |
| timeout_seconds | number | — | — |
| with_registry_auth | boolean | — | — |
No output schema declared.
No examples provided.
stack_list ~85
List the stacks deployed to the swarm, parsed from `--format '{{json .}}'`. Requires the target daemon to be a swarm manager. `compose_list` is the non-swarm equivalent; drill into one stack with `stack_services`. Raises RuntimeError if the CLI call fails. returns: list - One dict per stack (name, services count, orchestrator)
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
stack_ps ~167
List the tasks of a stack, parsed from `--format '{{json .}}'`. Task-level view across every service in the stack (`service_ps` covers one service): where each task runs and why it failed. Requires a swarm manager. Raises RuntimeError if the CLI call fails. args: name - The stack to list tasks for no_trunc - Do not truncate task IDs / errors in the output filters - Filter by attributes, e.g. {"desired-state": "running"}; a list value repeats the filter returns: list - One dict per task (id, name, node, image, desired/current state, error)
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | — | — |
| name | string | yes | — |
| no_trunc | boolean | — | — |
No output schema declared.
No examples provided.
stack_remove ~209
Remove one or more stacks from the swarm (tears down their services, networks, and secrets). Destructive: this stops and deletes every service in the named stack(s) — the reverse of `stack_deploy` and the swarm analogue of `compose_down`. Defaults to `detach=True` so the call returns once removal is requested rather than waiting for teardown. Does not raise on a non-zero CLI exit — inspect `returncode`/`stderr` in the result. args: names - One or more stack names to remove. At least one is required. detach - Return immediately (True) vs wait for the stack(s) to be fully removed (False) timeout_seconds - Subprocess timeout (default 300s) returns: dict - {"returncode": int, "stdout": str, "stderr": str, "truncated": bool}
| Name | Type | Req | Description |
|---|---|---|---|
| detach | boolean | — | — |
| names | array | yes | — |
| timeout_seconds | number | — | — |
No output schema declared.
No examples provided.
stack_services ~145
List the services of a stack, parsed from `--format '{{json .}}'`. Service-level rollup (replicas ready per service); use `stack_ps` for individual tasks and `service_inspect` for one service's full spec. Requires a swarm manager. Raises RuntimeError if the CLI call fails. args: name - The stack to list services for filters - Filter by attributes, e.g. {"name": "web"}; a list value repeats the filter returns: list - One dict per service (id, name, mode, replicas, image, ports)
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | — | — |
| name | string | yes | — |
No output schema declared.
No examples provided.
swarm_init ~418
Initialize a new swarm, making this Engine its first manager node. Fails if the Engine is already part of a swarm — call `swarm_leave` first to reset it. `advertise_addr` only needs setting when the host has multiple network interfaces or is behind NAT (otherwise it is auto-detected); it must be reachable by every other node that will join. To add more nodes afterwards, retrieve join tokens with `swarm_join_tokens` and call `swarm_join` on each one. Set `autolock_managers=True` to require the unlock key (`swarm_unlock_key`) on every manager restart — store that key securely immediately, since it is only shown once autolock is enabled. args: advertise_addr - Externally reachable address advertised to other nodes listen_addr - Listen address used for inter-manager communication force_new_cluster - Force a new single-node cluster from this node's current state (disaster recovery when a majority of managers is lost) default_addr_pool - IP address pools for swarm overlay networks subnet_size - Subnet size for the IP pool data_path_addr - Address to use for data path traffic data_path_port - Port number for data path traffic name - Name of the swarm labels - Labels to set on the swarm autolock_managers - Require the unlock key after every manager restart log_driver - Default log driver configuration returns: str - The node id of the newly created swarm manager
| Name | Type | Req | Description |
|---|---|---|---|
| advertise_addr | string | — | — |
| autolock_managers | boolean | — | — |
| data_path_addr | string | — | — |
| data_path_port | integer | — | — |
| default_addr_pool | array | — | — |
| force_new_cluster | boolean | — | — |
| labels | object | — | — |
| listen_addr | string | — | — |
| log_driver | object | — | — |
| name | string | — | — |
| subnet_size | integer | — | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | — |
No examples provided.
swarm_inspect ~82
Inspect the swarm this daemon belongs to (id, spec, join-token config, CA info). Works on a manager node only. Cluster-level configuration — for per-node state use `node_list`; for the tokens new nodes need, `swarm_join_tokens`. returns: dict - The swarm's attrs, as returned by the daemon's swarm inspect endpoint
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
swarm_join ~269
Join this Engine to an existing swarm as a worker or manager. Fails if the Engine is already part of a swarm. Whether this node joins as a worker or a manager is determined entirely by which token is passed — `join_token` must be one of the two tokens from `swarm_join_tokens`, called against any existing manager. `advertise_addr` only needs setting when this host has multiple network interfaces or is behind NAT (otherwise it is auto-detected from the interface used to reach `remote_addrs`); it must be reachable by every other node in the swarm. args: remote_addrs - Address(es) of existing swarm managers to connect to join_token - The worker or manager join token (from `swarm_join_tokens`) — determines the role this node joins as listen_addr - Listen address for inter-manager communication advertise_addr - Externally reachable address advertised to other nodes data_path_addr - Address to use for data path traffic returns: bool - True after the engine joins the swarm
| Name | Type | Req | Description |
|---|---|---|---|
| advertise_addr | string | — | — |
| data_path_addr | string | — | — |
| join_token | string | yes | — |
| listen_addr | string | — | — |
| remote_addrs | array | yes | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
swarm_join_tokens ~131
Return the swarm's worker and manager join tokens. These are the tokens a new node passes to `swarm_join` — without one, `swarm_join` cannot be called, so this closes the init -> join loop. The tokens are secret bearer credentials (anyone holding the manager token can join as a manager); treat the result as sensitive and avoid logging it. Reads `swarm.attrs["JoinTokens"]` after a reload, so it always reflects the current tokens. returns: dict - {"Worker": <worker join token>, "Manager": <manager join token>}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
swarm_leave ~97
Leave the current swarm. The daemon's service tasks are rescheduled to the remaining nodes. A manager refuses to leave without force=True, since leaving can break raft quorum. The departed node lingers as "down" in `node_list` until a manager runs `node_remove`. args: force - Force leave even if the node is a manager returns: bool - True after leaving the swarm
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | — | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
swarm_unlock ~177
Unlock a manager node that is locked after restart due to autolock being enabled. When autolock is enabled (via `swarm_init` or `swarm_update`), manager nodes require the unlock key after every restart before they can rejoin the swarm and resume scheduling. Must be called on the locked manager node directly. Retrieve the current unlock key with `swarm_unlock_key` from any unlocked manager — store it securely when enabling autolock. A locked node cannot serve API requests and cannot return its own key while locked; other unlocked managers in the swarm can still serve the key. Once unlocked the manager resumes automatically. args: key - The swarm unlock key (from `swarm_unlock_key`) returns: bool - True after the swarm is unlocked
| Name | Type | Req | Description |
|---|---|---|---|
| key | string | yes | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
swarm_unlock_key ~124
Return the swarm's current unlock key. The key only serves a purpose when autolock is enabled (see `swarm_init`'s / `swarm_update`'s `autolock_managers` / `rotate_manager_unlock_key`). Must be called against an unlocked manager — a locked manager cannot serve API requests, including this one. Feed the result's key to `swarm_unlock` to unlock a manager after restart. Treat the key as a sensitive credential. returns: dict - {"UnlockKey": <the current unlock key>}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
swarm_update ~209
Update swarm-wide settings: the single home for join-token and unlock-key rotation. Must be called on a swarm manager node. Token rotation invalidates the old join token immediately — nodes that have not yet joined using the old token must use the new one. Existing joined nodes are unaffected. Use `swarm_join_tokens` to retrieve the new tokens after rotation. Rotating the unlock key requires all managers to be re-unlocked on restart with the new key; retrieve it immediately via `swarm_unlock_key`. args: rotate_worker_token - Issue a new worker join token, invalidating the current one rotate_manager_token - Issue a new manager join token, invalidating the current one rotate_manager_unlock_key - Issue a new autolock unlock key for manager restart returns: bool - True after the update completes
| Name | Type | Req | Description |
|---|---|---|---|
| rotate_manager_token | boolean | — | — |
| rotate_manager_unlock_key | boolean | — | — |
| rotate_worker_token | boolean | — | — |
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
system_close ~114
Close and drop pooled Docker client connection(s); each is rebuilt lazily on next use. Use this to force a stale or errored connection to be discarded. Prefer `system_reconnect` when you want to immediately re-establish the connection rather than wait for the next tool call to trigger a lazy rebuild. With `host` omitted every pooled client is closed (unlike other tools, where omitting it means the default host). Closing clients does not affect running containers. returns: bool - True once closed
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.
system_df ~135
Summarize Docker disk usage: layer storage plus per-object sizes for images, containers, volumes, build cache. Equivalent to `docker system df`. Use it to find what to reclaim before `image_prune` / `container_prune` / `volume_prune` / `buildx_prune`; use `system_info` for daemon config and counts rather than sizes. The reply enumerates every object on the daemon, so expect a large payload on busy hosts. returns: dict - {"LayersSize", "Images", "Containers", "Volumes", "BuildCache"} with per-object size fields
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
system_events ~359
Stream real-time events from the Docker server, bounded by `limit` events or `timeout_seconds`. Returns when `limit` events are collected or `timeout_seconds` elapses, whichever comes first (`limit` caps memory; `timeout_seconds` caps how long the call blocks — without it a quiet daemon would block indefinitely, since the stream only yields on an actual event). Caveat for `ssh://` daemons: docker-py can't cancel an SSH stream, so the `timeout_seconds` watchdog can't interrupt a fully idle stream — bound with `until`/`limit` (or a non-SSH endpoint). "Wait for the next matching event" idiom: pass `limit=1` with `filters` narrowed to what you care about (e.g. `{"type": "container", "event": "health_status"}`) and a generous `timeout_seconds`. This blocks until that one event arrives (or the timeout elapses, returning an empty list) instead of re-polling a snapshot on a timer — there's no separate wait tool for this since the filtering this call already does covers it. args: since - Show events created since this timestamp until - Show events created until this timestamp filters - Filters to apply to the event stream limit - Max events to return (default 100) timeout_seconds - Max wall-clock seconds before returning what was collected (default 30) returns: list - A list of decoded event dicts (length <= limit)
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | — | — |
| limit | integer | — | — |
| since | string | — | — |
| timeout_seconds | number | — | — |
| until | string | — | — |
No output schema declared.
No examples provided.
system_info ~85
Return system-wide Docker information, like `docker info`. Daemon runtime state: container/image counts, storage and logging drivers, swarm role, and daemon warnings. Use `system_version` for version/API level and `system_df` for disk usage. returns: dict - {"Containers", "Images", "Driver", "ServerVersion", "Swarm", "Warnings", ...}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
system_login ~233
Authenticate with a Docker registry. Security: the password is sent as a tool argument, which many MCP clients log verbatim. Prefer running `docker login` once on the host so the `docker` module reuses the credentials cached in `~/.docker/config.json`, and avoid calling this tool from an agent loop. Credentials let `image_pull` / `image_push` reach private repositories; `system_logout` clears them. args: username - Registry username password - Registry password or token email - Registry account email registry - URL to the registry (defaults to Docker Hub) reauth - Force re-authentication even if valid credentials exist dockercfg_path - Path to a custom dockercfg file returns: dict - The login response: {"Status"} always; "IdentityToken" only when the registry issues one
| Name | Type | Req | Description |
|---|---|---|---|
| dockercfg_path | string | — | — |
| string | — | — | |
| password | string | yes | — |
| reauth | boolean | — | — |
| registry | string | — | — |
| username | string | yes | — |
No output schema declared.
No examples provided.
system_logout ~209
Clear cached registry credentials from this server's in-memory Docker client. docker-py / the Engine have no true logout: `system_login` validates against the registry (the daemon's `/auth` is stateless) and caches credentials in-process. This drops that in-memory cache; it does NOT contact the daemon or touch the host's `~/.docker/config.json`. With no `registry`, clears every cached credential; pass one to clear just that entry (key must match `system_login`; Docker Hub is cached under "docker.io"). `system_close`/`system_reconnect` also clear it by discarding the client. Reaches into a private docker-py attribute (`api._auth_configs`); degrades to clearing nothing if that internal shape changes. args: registry - Registry key to clear, or None to clear every cached credential returns: dict - {"cleared": [<registry keys removed>]}
| Name | Type | Req | Description |
|---|---|---|---|
| registry | string | — | — |
No output schema declared.
No examples provided.
system_ping ~83
Check that the Docker server is responsive. The cheapest daemon health check. A failure here usually means connection config rather than daemon load — `system_reconnect` rebuilds a wedged client, `host_list` shows the configured endpoints. For daemon details use `system_version` / `system_info`. returns: bool - True if the daemon responded successfully
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | boolean | yes | — |
No examples provided.