docker-mcp-server 2.2.4__tar.gz → 2.2.5__tar.gz

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/.github/copilot-instructions.md

@@ -304,7 +304,7 @@ When the high-level SDK lacks a method (e.g. swarm node removal, service rollbac
 
 Treat "the method exists" as separate from "the method works": the rendered docs show a docstring, not the URL a method builds. `plugin_push` is the standing example — docker-py's `Plugin.push()` / `APIClient.push_plugin()` POST to `/plugins/{name}/pull`, which the Engine does not define (push is `POST /plugins/{name}/push`), so they 404 everywhere; broken since 2017 and still in `main`, because upstream has no test for it. Where a documented method is provably broken, the ladder is: another public SDK path, then the correct endpoint via docker-py's private request helpers (`_url`/`_post`/`_raise_for_status`/`_stream_helper`) resolved through `getattr` and guarded to raise an actionable message rather than `AttributeError` (as `system_logout` does with `api._auth_configs`), then a CLI shell-out if the domain is already CLI-backed. Anything below the first rung leaves the supported surface and is **a human's call, not an agent's**: a PR that adds a *new* private-helper reach-in should be flagged as needing explicit maintainer sign-off, even when it is well built — say so rather than approving it on the strength of the guards. Do flag one that is unguarded, undocumented, or that hits an endpoint absent from the Engine API spec (no compatibility promise, no deprecation cycle — a categorically worse bet than `plugin_push`'s, which uses a spec'd endpoint the CLI itself calls and reaches it through unofficial plumbing). Do **not** re-litigate the reach-ins already blessed above (`plugin_push`, `system_logout`, `stage_build_context`): being present on `main` *is* the sign-off, so a PR that merely touches or refactors one needs no fresh approval — only a genuinely new reach-in does. If a diff both adds and blesses one, that has already been decided; say nothing. And do not treat an audit or routine that *declined* to implement something and documented why as an unfinished job — that write-up is the intended escalation path, and is how `plugin_push` reached a human decision in the first place.
 
-**SDK audit exclusions.** A recurring audit routine looks for uncovered SDK surface and for low-level `client.api.*` calls a high-level method could replace. These were decided on the merits and must not be re-proposed (in review or by the routine): `Plugin.push()`/`APIClient.push_plugin()` — broken upstream, so `plugin_push`'s hand-built endpoint call is the working path, not debt to tidy away; `Container.attach`/`attach_socket`/`resize` — deliberately unwrapped, as an interactive bidirectional stream doesn't fit a request/response tool call (`container_exec` covers scripted exec); `service_rollback`'s `inspect_service`/`update_service` and `system_logout`'s `_auth_configs` — permanently low-level, as the high-level SDK has no `rollback` and no `logout` at all. Anything deliberately not wrapped, or wrapped unobviously, belongs on that list in `CLAUDE.md`.
+**SDK audit exclusions.** A recurring audit routine looks for uncovered SDK surface and for low-level `client.api.*` calls a high-level method could replace. These were decided on the merits and must not be re-proposed (in review or by the routine): `Plugin.push()`/`APIClient.push_plugin()` — broken upstream, so `plugin_push`'s hand-built endpoint call is the working path, not debt to tidy away; `Container.attach`/`attach_socket`/`resize` — deliberately unwrapped, as an interactive bidirectional stream doesn't fit a request/response tool call (`container_exec` covers scripted exec); `service_rollback`'s `inspect_service`/`update_service` and `system_logout`'s `_auth_configs` — permanently low-level, as the high-level SDK has no `rollback` and no `logout` at all; `swarm_task_list`/`swarm_task_inspect`'s `api.tasks()`/`api.inspect_task()` — permanently low-level, as docker-py has no task collection at all. Anything deliberately not wrapped, or wrapped unobviously, belongs on that list in `CLAUDE.md`.
 
 Docker SDK docs: https://docker-py.readthedocs.io/en/stable/index.html
 Docker SDK low-level API: https://docker-py.readthedocs.io/en/stable/api.html

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/.mcpbignore

@@ -13,6 +13,10 @@ scripts/
 # server, not part of it — packing it here would ship ~140 KB of markdown the bundle never reads.
 skills/
 .github/
+# Claude Code project config: the mirror-rule PostToolUse hook and the /docker-sdk command. Both are
+# development tooling for this repo, meaningless to an installed bundle, and 2.2.4 shipped them by
+# omission. `.dockerignore` already excludes this directory.
+.claude/
 .idea/
 .vscode/
 .pytest_cache/

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/CLAUDE.md

@@ -516,6 +516,10 @@ say why. **Anything deliberately not wrapped, or wrapped in an unobvious way, be
   permanently. The high-level `Service`/`ServiceCollection` expose no `rollback`.
 - **`system_logout`'s `api._auth_configs`** — stays low-level permanently. There is no `logout`
   anywhere in the SDK and no server-side session to end, so there is nothing to migrate to.
+- **`swarm_task_list` / `swarm_task_inspect`'s `api.tasks()` / `api.inspect_task()`** — stay
+  low-level permanently. docker-py has no task collection at all (there is no `client.tasks`, and
+  `docker/models/` has no `tasks.py`), so these documented `APIClient` methods are the only public
+  path. Nothing to migrate to; do not propose one.
 
 The audit must also **check the latest published docker-py, not the pinned one**: `uv.lock` is
 routinely behind what `pyproject.toml`'s floor lets a fresh `uvx`/`pip install` resolve, so auditing

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/MCP_VS_SKILLS.md

@@ -419,7 +419,7 @@ Legend: **✓** direct CLI equivalent; **≈** covered by a documented recipe (l
 | container_wait (exit) ✓ | `docker wait` |
 | container_wait (healthy) ≈ | `wait_healthy` loop, `reference/observability.md` |
 
-### images (14) - `reference/images.md`
+### images (15) - `reference/images.md`
 
 | Tool | CLI |
 |---|---|
@@ -431,6 +431,7 @@ Legend: **✓** direct CLI equivalent; **≈** covered by a documented recipe (l
 | image_history ✓ | `docker history` |
 | image_inspect ✓ | `docker image inspect` |
 | image_save / load ✓ | `docker save -o` / `load -i` |
+| image_import ✓ | `docker import` |
 | image_prune ✓ | `docker image prune` |
 | image_prune_builds ✓ | `docker builder prune` (`--reserved-space`, ex-`--keep-storage`) |
 | image_search ✓ | `docker search` (Hub only) |
@@ -447,7 +448,7 @@ All ✓ - each maps to the identically-named `docker compose <sub>`: `up`, `down
 `logs`, `build`, `pull`, `config`, `cp`, `exec`, `run`, `start`, `stop`, `restart`, `kill`,
 `pause`, `unpause`, `port`, `top`, `images`, `wait`. (`compose_list` → `docker compose ls`.)
 
-### swarm (8) / services (10) / nodes (5) / secrets (4) / configs (4) / stack (5) - `reference/swarm.md`
+### swarm (10) / services (10) / nodes (5) / secrets (4) / configs (4) / stack (5) - `reference/swarm.md`
 
 | Tool | CLI |
 |---|---|
@@ -455,6 +456,8 @@ All ✓ - each maps to the identically-named `docker compose <sub>`: `up`, `down
 | swarm_join_tokens ✓ | `docker swarm join-token <worker\|manager>` |
 | swarm_unlock / unlock_key ✓ | `docker swarm unlock` / `unlock-key` |
 | swarm_inspect ✓ | `docker info --format '{{json .Swarm}}'` |
+| swarm_task_list ≈ | `docker service ps $(docker service ls -q)`, `reference/swarm.md` - no CLI command lists the cluster's tasks in one shot |
+| swarm_task_inspect ✓ | `docker inspect --type task` |
 | service_create / update / remove / logs / ps / inspect / list ✓ | `docker service <sub>` |
 | service_scale ✓ | `docker service scale` |
 | service_rollback ✓ | `docker service rollback` |
@@ -477,10 +480,15 @@ All ✓: `docker scout cves/quickview/compare/recommendations/sbom`.
 
 All ✓: `docker context create/ls/inspect/rm/use`.
 
-### plugins (10) - `reference/system.md`
+### plugins (11) - `reference/system.md`
 
 All ✓: `docker plugin install/ls/inspect/enable/disable/set/upgrade/rm/push/create`.
 `plugin_configure` → `docker plugin set`.
+`plugin_privileges` ≈ no `docker plugin` subcommand prints them, and `docker plugin inspect` needs
+the plugin installed first; the skill reads the plugin's registry config blob over `curl` instead
+(`reference/system.md`), reproducing the install prompt's privilege list without installing
+anything. The recipe mirrors the daemon's own `computePrivileges`, so it reports whichever of the
+seven privilege kinds a given plugin declares rather than a fixed subset.
 
 ### registry (7) - `reference/registry.md`
 

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: docker-mcp-server
-Version: 2.2.4
+Version: 2.2.5
 Summary: MCP server for managing Docker resources via the Docker SDK for Python
 Project-URL: Homepage, https://github.com/L337-org/docker-mcp
 Project-URL: Repository, https://github.com/L337-org/docker-mcp
@@ -265,10 +265,10 @@ Everything above targets one daemon. To manage **several in a single session** -
 Once loaded, the agent gets MCP tools grouped by Docker domain. A few examples:
 
 - **Containers** - `container_run`, `container_list` (`managed_only=True` to list only what this server created - see [Provenance labels](#provenance-labels)), `container_exec`, `container_logs`, `container_stop`, `container_commit`, `container_wait` (block until exit, `until="healthy"` to poll a healthcheck, or `until="log-match"` to poll for a log line containing `pattern`), `container_export` / `container_archive_get_to_file` / `container_archive_put` (stream tar archives to/from a host path)
-- **Images** - `image_build`, `image_pull`, `image_push`, `image_tag`, `image_prune`, `image_prune_builds` (clear the daemon's build cache - a separate resource from dangling images), `image_save` / `image_load` (stream image tarballs to/from a host path via `dest_path` / `from_file`)
-- **Plugins** - `plugin_install` (pull from a registry), `plugin_create` (build one from a local `config.json` + `rootfs`), `plugin_push` (publish it back), `plugin_enable` / `plugin_disable`, `plugin_configure`, `plugin_upgrade`, `plugin_list` / `plugin_inspect`, `plugin_remove` *(managed engine plugins - volume/network/logging drivers - not the CLI plugins that extend the `docker` command itself)*
+- **Images** - `image_build`, `image_pull`, `image_push`, `image_tag`, `image_prune`, `image_prune_builds` (clear the daemon's build cache - a separate resource from dangling images), `image_save` / `image_load` (stream image tarballs to/from a host path via `dest_path` / `from_file`), `image_import` (build a single-layer image from a flat rootfs tarball, URL, or existing image - `docker import`, not to be confused with `image_load`)
+- **Plugins** - `plugin_install` (pull from a registry), `plugin_privileges` (read what host access a plugin demands *before* installing it - the daemon grants them non-interactively), `plugin_create` (build one from a local `config.json` + `rootfs`), `plugin_push` (publish it back), `plugin_enable` / `plugin_disable`, `plugin_configure`, `plugin_upgrade`, `plugin_list` / `plugin_inspect`, `plugin_remove` *(managed engine plugins - volume/network/logging drivers - not the CLI plugins that extend the `docker` command itself)*
 - **Networks / Volumes** - `network_create`, `network_connect`, `volume_create`, `volume_prune`
-- **Swarm** - `swarm_init`, `swarm_join_tokens` (close the init → join loop), `swarm_update` (rotate join tokens / unlock key), `service_create`, `service_scale`, `service_rollback` (re-apply the previous service spec), `service_wait` (block until tasks converge, or a rolling update completes), `node_list`, `node_wait` (block until a node reaches a target state - e.g. `ready` after joining), `node_remove`, `secret_create`, `config_create`
+- **Swarm** - `swarm_init`, `swarm_join_tokens` (close the init → join loop), `swarm_update` (rotate join tokens / unlock key), `service_create`, `service_scale`, `service_rollback` (re-apply the previous service spec), `service_wait` (block until tasks converge, or a rolling update completes), `swarm_task_list` / `swarm_task_inspect` (every task in the cluster, filterable by node or desired state - no single CLI command does this), `node_list`, `node_wait` (block until a node reaches a target state - e.g. `ready` after joining), `node_remove`, `secret_create`, `config_create`
 - **System** - `system_ping`, `system_info`, `system_version`, `system_df`, `system_events`, `host_list` (the configured daemons and which is the default - see [Managing several daemons](#managing-several-daemons)), `system_login` / `system_logout` (cache or clear registry credentials), `system_reconnect` (rebuild a host's SDK client to recover a wedged connection)
 - **Compose** - `compose_up`, `compose_down`, `compose_stop`, `compose_start`, `compose_restart`, `compose_pause` / `compose_unpause`, `compose_kill`, `compose_ps`, `compose_list`, `compose_images`, `compose_top`, `compose_port`, `compose_logs`, `compose_config`, `compose_build`, `compose_pull`, `compose_run`, `compose_exec`, `compose_cp`, `compose_wait` *(wraps the `docker compose` CLI plugin)*
 - **Stacks** - `stack_deploy`, `stack_list`, `stack_ps`, `stack_services`, `stack_remove` *(deploy a Compose file to a swarm as a stack; wraps the `docker stack` CLI - requires a swarm manager)*
@@ -460,7 +460,7 @@ Connecting this server to an AI agent grants it the same level of access as a lo
 - **Swarm secret material transits tool calls too.** Beyond registry credentials, several swarm tools carry secret material through arguments or return values that MCP clients may log: `secret_create(data=...)` and `config_create(data=...)` take the payload as an argument, `secret_inspect` / `config_inspect` return the stored object, `swarm_join(join_token=...)` and `swarm_unlock(key=...)` take cluster join/unlock secrets, and `swarm_unlock_key` and `swarm_join_tokens` *return* cluster credentials (rotation via `swarm_update` invalidates old tokens) - a manager join token lets its holder join the swarm as a manager (root-equivalent on the cluster). Treat all of these as exposed in any client that records tool traffic, and prefer provisioning swarm secrets and reading join tokens out-of-band on the host rather than through the agent. If an agent never needs to admit nodes, drop the whole surface with `DOCKER_MCP_SERVER_DISABLE=swarm` (see [Configuration](#configuration)).
 - **`container_exec`, `compose_exec`, and `compose_run` run arbitrary commands.** When any part of the command is derived from agent-controlled input, use an exec-form argv list that does not invoke a shell (e.g. `["python", "-V"]`). A list like `["sh", "-c", template]` that invokes a shell will interpret shell metacharacters in the untrusted substrings.
 - **Container archive paths.** `container_archive_get` and `container_archive_put` forward the supplied path verbatim to the daemon. The container is the trust boundary - if you do not trust its filesystem, do not assume `..` traversal will be rejected.
-- **File-path payload tools read and write the server host's filesystem.** `image_save`, `container_export` (with `dest_path`), and `container_archive_get_to_file` write to a `dest_path` on the host running this MCP server (refusing to overwrite an existing file unless `overwrite=True`); `image_load` and `container_archive_put` (with `from_file`) read a host path; `compose_cp` copies between a service container and a host path in either direction. These run as the server's user, so the agent can write any file that user can write and read any file it can read. Prefer the in-band byte tools (capped at 32 MiB) when you don't trust the agent with host filesystem access. `DOCKER_MCP_SERVER_READONLY` also drops the host-writing tools - but note it is not targeted at them: it registers *only* read-only tools, so `image_load` and `container_archive_put` (and every other mutating/destructive tool) go too. There is no switch that drops just the file-writers.
+- **File-path payload tools read and write the server host's filesystem.** `image_save`, `container_export` (with `dest_path`), and `container_archive_get_to_file` write to a `dest_path` on the host running this MCP server (refusing to overwrite an existing file unless `overwrite=True`); `image_load`, `image_import`, and `container_archive_put` (with `from_file`) read a host path; `compose_cp` copies between a service container and a host path in either direction. `image_import(from_url=...)` is the one that leaves the host entirely: the *daemon* fetches the URL the caller named, in the daemon's own network namespace, so it can reach anything that daemon can reach (the same caller-chooses-the-destination footing as `image_pull`'s registry argument). These run as the server's user, so the agent can write any file that user can write and read any file it can read. Prefer the in-band byte tools (capped at 32 MiB) when you don't trust the agent with host filesystem access. `DOCKER_MCP_SERVER_READONLY` also drops the host-writing tools - but note it is not targeted at them: it registers *only* read-only tools, so `image_load` and `container_archive_put` (and every other mutating/destructive tool) go too. There is no switch that drops just the file-writers.
 - **Destructive operations have no built-in confirmation.** `prune_*`, `remove_*`, `container_kill`, `swarm_leave`, `compose_down(volumes=True)`, `compose_kill`, `stack_remove` (tears down every service in a stack), `buildx_prune` (always runs with `--force`), and `buildx_remove` execute immediately. These tools carry the `destructiveHint` annotation, so a client like Claude Code can gate them, and the shipped `clean_environment` prompt asks the agent to confirm before pruning volumes - but tool calls themselves are not gated by the server. For a hard guarantee, run with `DOCKER_MCP_SERVER_NO_DESTRUCTIVE=1` (drops them entirely) or `DOCKER_MCP_SERVER_READONLY=1` (see [Configuration](#configuration)); for an approval step, configure it at the MCP client.
 - **CLI shell-out attack surface.** Compose, Stack, Buildx, Scout, and Context tools spawn `docker` subprocesses on the host running this MCP server. Every invocation passes arguments as a list (no shell, no metacharacter interpretation), resolves the binary via `shutil.which`, and runs against a scrubbed environment (DOCKER_HOST and related vars only). Positional values (image refs, service / context / builder names, build contexts, bake targets) are additionally rejected if they start with `-`, so an argument can't be smuggled in as a CLI flag (e.g. a service named `--output=...`); the one deliberate exception is the trailing command in `compose_exec` / `compose_run`, which is meant to be an arbitrary argv. Filesystem paths supplied to `compose_*` (project_dir, files) are read by the docker CLI on the server host - passing an unfamiliar path can expose any compose file the server's user can read. **With no local docker CLI and an `ssh://` target** those subprocesses run on the remote host instead ([above](#talking-to-a-remote-daemon)), which shifts two things: the command executes as the remote SSH user with *its* registry credentials, and the files a command reads are copied to that host's temp directory first - so a `buildx_build` `--secret src=` file, or anything else in a staged directory, exists briefly on the remote disk (mode `0700`, removed when the call returns; only a dropped connection can leave it behind). Point staging-backed tools at directories you would be content to copy.
 - **The daemon set is fixed at startup; pick it deliberately.** When `DOCKER_HOST` / `DOCKER_MCP_SERVER_HOSTS` are unset, the server's *initial* SDK connection follows your active Docker context (`DOCKER_CONTEXT` / `currentContext`) - the same daemon your `docker` CLI targets - so if that context points at a remote or production daemon, the agent connects there too. Set `DOCKER_MCP_SERVER_HOSTS` (or `DOCKER_HOST`, or select a scoped context) before starting the server to pin the target(s) deliberately; with `DOCKER_MCP_SERVER_HOSTS` the `auto`/`local` endpoints are resolved and **pinned at startup**, so they can't drift if a context changes later. After startup, `context_use` only changes the CLI default for subsequent CLI-backed tools; SDK-backed tools keep using the daemon their pooled client connected to. **There is no runtime way to introduce or retarget a daemon at an arbitrary endpoint** - `system_reconnect` only *rebuilds* an already-configured host's client (to recover a wedged connection), it can't point it elsewhere; to add or change a daemon, edit `DOCKER_MCP_SERVER_HOSTS` and restart. This deliberately closes a trust-expansion vector (an agent can't move the root-equivalent boundary to an unvetted endpoint mid-session). `context_create(skip_tls_verify=True)` disables TLS verification for a context; use only against trusted local daemons.

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/README.md

@@ -238,10 +238,10 @@ Everything above targets one daemon. To manage **several in a single session** -
 Once loaded, the agent gets MCP tools grouped by Docker domain. A few examples:
 
 - **Containers** - `container_run`, `container_list` (`managed_only=True` to list only what this server created - see [Provenance labels](#provenance-labels)), `container_exec`, `container_logs`, `container_stop`, `container_commit`, `container_wait` (block until exit, `until="healthy"` to poll a healthcheck, or `until="log-match"` to poll for a log line containing `pattern`), `container_export` / `container_archive_get_to_file` / `container_archive_put` (stream tar archives to/from a host path)
-- **Images** - `image_build`, `image_pull`, `image_push`, `image_tag`, `image_prune`, `image_prune_builds` (clear the daemon's build cache - a separate resource from dangling images), `image_save` / `image_load` (stream image tarballs to/from a host path via `dest_path` / `from_file`)
-- **Plugins** - `plugin_install` (pull from a registry), `plugin_create` (build one from a local `config.json` + `rootfs`), `plugin_push` (publish it back), `plugin_enable` / `plugin_disable`, `plugin_configure`, `plugin_upgrade`, `plugin_list` / `plugin_inspect`, `plugin_remove` *(managed engine plugins - volume/network/logging drivers - not the CLI plugins that extend the `docker` command itself)*
+- **Images** - `image_build`, `image_pull`, `image_push`, `image_tag`, `image_prune`, `image_prune_builds` (clear the daemon's build cache - a separate resource from dangling images), `image_save` / `image_load` (stream image tarballs to/from a host path via `dest_path` / `from_file`), `image_import` (build a single-layer image from a flat rootfs tarball, URL, or existing image - `docker import`, not to be confused with `image_load`)
+- **Plugins** - `plugin_install` (pull from a registry), `plugin_privileges` (read what host access a plugin demands *before* installing it - the daemon grants them non-interactively), `plugin_create` (build one from a local `config.json` + `rootfs`), `plugin_push` (publish it back), `plugin_enable` / `plugin_disable`, `plugin_configure`, `plugin_upgrade`, `plugin_list` / `plugin_inspect`, `plugin_remove` *(managed engine plugins - volume/network/logging drivers - not the CLI plugins that extend the `docker` command itself)*
 - **Networks / Volumes** - `network_create`, `network_connect`, `volume_create`, `volume_prune`
-- **Swarm** - `swarm_init`, `swarm_join_tokens` (close the init → join loop), `swarm_update` (rotate join tokens / unlock key), `service_create`, `service_scale`, `service_rollback` (re-apply the previous service spec), `service_wait` (block until tasks converge, or a rolling update completes), `node_list`, `node_wait` (block until a node reaches a target state - e.g. `ready` after joining), `node_remove`, `secret_create`, `config_create`
+- **Swarm** - `swarm_init`, `swarm_join_tokens` (close the init → join loop), `swarm_update` (rotate join tokens / unlock key), `service_create`, `service_scale`, `service_rollback` (re-apply the previous service spec), `service_wait` (block until tasks converge, or a rolling update completes), `swarm_task_list` / `swarm_task_inspect` (every task in the cluster, filterable by node or desired state - no single CLI command does this), `node_list`, `node_wait` (block until a node reaches a target state - e.g. `ready` after joining), `node_remove`, `secret_create`, `config_create`
 - **System** - `system_ping`, `system_info`, `system_version`, `system_df`, `system_events`, `host_list` (the configured daemons and which is the default - see [Managing several daemons](#managing-several-daemons)), `system_login` / `system_logout` (cache or clear registry credentials), `system_reconnect` (rebuild a host's SDK client to recover a wedged connection)
 - **Compose** - `compose_up`, `compose_down`, `compose_stop`, `compose_start`, `compose_restart`, `compose_pause` / `compose_unpause`, `compose_kill`, `compose_ps`, `compose_list`, `compose_images`, `compose_top`, `compose_port`, `compose_logs`, `compose_config`, `compose_build`, `compose_pull`, `compose_run`, `compose_exec`, `compose_cp`, `compose_wait` *(wraps the `docker compose` CLI plugin)*
 - **Stacks** - `stack_deploy`, `stack_list`, `stack_ps`, `stack_services`, `stack_remove` *(deploy a Compose file to a swarm as a stack; wraps the `docker stack` CLI - requires a swarm manager)*
@@ -433,7 +433,7 @@ Connecting this server to an AI agent grants it the same level of access as a lo
 - **Swarm secret material transits tool calls too.** Beyond registry credentials, several swarm tools carry secret material through arguments or return values that MCP clients may log: `secret_create(data=...)` and `config_create(data=...)` take the payload as an argument, `secret_inspect` / `config_inspect` return the stored object, `swarm_join(join_token=...)` and `swarm_unlock(key=...)` take cluster join/unlock secrets, and `swarm_unlock_key` and `swarm_join_tokens` *return* cluster credentials (rotation via `swarm_update` invalidates old tokens) - a manager join token lets its holder join the swarm as a manager (root-equivalent on the cluster). Treat all of these as exposed in any client that records tool traffic, and prefer provisioning swarm secrets and reading join tokens out-of-band on the host rather than through the agent. If an agent never needs to admit nodes, drop the whole surface with `DOCKER_MCP_SERVER_DISABLE=swarm` (see [Configuration](#configuration)).
 - **`container_exec`, `compose_exec`, and `compose_run` run arbitrary commands.** When any part of the command is derived from agent-controlled input, use an exec-form argv list that does not invoke a shell (e.g. `["python", "-V"]`). A list like `["sh", "-c", template]` that invokes a shell will interpret shell metacharacters in the untrusted substrings.
 - **Container archive paths.** `container_archive_get` and `container_archive_put` forward the supplied path verbatim to the daemon. The container is the trust boundary - if you do not trust its filesystem, do not assume `..` traversal will be rejected.
-- **File-path payload tools read and write the server host's filesystem.** `image_save`, `container_export` (with `dest_path`), and `container_archive_get_to_file` write to a `dest_path` on the host running this MCP server (refusing to overwrite an existing file unless `overwrite=True`); `image_load` and `container_archive_put` (with `from_file`) read a host path; `compose_cp` copies between a service container and a host path in either direction. These run as the server's user, so the agent can write any file that user can write and read any file it can read. Prefer the in-band byte tools (capped at 32 MiB) when you don't trust the agent with host filesystem access. `DOCKER_MCP_SERVER_READONLY` also drops the host-writing tools - but note it is not targeted at them: it registers *only* read-only tools, so `image_load` and `container_archive_put` (and every other mutating/destructive tool) go too. There is no switch that drops just the file-writers.
+- **File-path payload tools read and write the server host's filesystem.** `image_save`, `container_export` (with `dest_path`), and `container_archive_get_to_file` write to a `dest_path` on the host running this MCP server (refusing to overwrite an existing file unless `overwrite=True`); `image_load`, `image_import`, and `container_archive_put` (with `from_file`) read a host path; `compose_cp` copies between a service container and a host path in either direction. `image_import(from_url=...)` is the one that leaves the host entirely: the *daemon* fetches the URL the caller named, in the daemon's own network namespace, so it can reach anything that daemon can reach (the same caller-chooses-the-destination footing as `image_pull`'s registry argument). These run as the server's user, so the agent can write any file that user can write and read any file it can read. Prefer the in-band byte tools (capped at 32 MiB) when you don't trust the agent with host filesystem access. `DOCKER_MCP_SERVER_READONLY` also drops the host-writing tools - but note it is not targeted at them: it registers *only* read-only tools, so `image_load` and `container_archive_put` (and every other mutating/destructive tool) go too. There is no switch that drops just the file-writers.
 - **Destructive operations have no built-in confirmation.** `prune_*`, `remove_*`, `container_kill`, `swarm_leave`, `compose_down(volumes=True)`, `compose_kill`, `stack_remove` (tears down every service in a stack), `buildx_prune` (always runs with `--force`), and `buildx_remove` execute immediately. These tools carry the `destructiveHint` annotation, so a client like Claude Code can gate them, and the shipped `clean_environment` prompt asks the agent to confirm before pruning volumes - but tool calls themselves are not gated by the server. For a hard guarantee, run with `DOCKER_MCP_SERVER_NO_DESTRUCTIVE=1` (drops them entirely) or `DOCKER_MCP_SERVER_READONLY=1` (see [Configuration](#configuration)); for an approval step, configure it at the MCP client.
 - **CLI shell-out attack surface.** Compose, Stack, Buildx, Scout, and Context tools spawn `docker` subprocesses on the host running this MCP server. Every invocation passes arguments as a list (no shell, no metacharacter interpretation), resolves the binary via `shutil.which`, and runs against a scrubbed environment (DOCKER_HOST and related vars only). Positional values (image refs, service / context / builder names, build contexts, bake targets) are additionally rejected if they start with `-`, so an argument can't be smuggled in as a CLI flag (e.g. a service named `--output=...`); the one deliberate exception is the trailing command in `compose_exec` / `compose_run`, which is meant to be an arbitrary argv. Filesystem paths supplied to `compose_*` (project_dir, files) are read by the docker CLI on the server host - passing an unfamiliar path can expose any compose file the server's user can read. **With no local docker CLI and an `ssh://` target** those subprocesses run on the remote host instead ([above](#talking-to-a-remote-daemon)), which shifts two things: the command executes as the remote SSH user with *its* registry credentials, and the files a command reads are copied to that host's temp directory first - so a `buildx_build` `--secret src=` file, or anything else in a staged directory, exists briefly on the remote disk (mode `0700`, removed when the call returns; only a dropped connection can leave it behind). Point staging-backed tools at directories you would be content to copy.
 - **The daemon set is fixed at startup; pick it deliberately.** When `DOCKER_HOST` / `DOCKER_MCP_SERVER_HOSTS` are unset, the server's *initial* SDK connection follows your active Docker context (`DOCKER_CONTEXT` / `currentContext`) - the same daemon your `docker` CLI targets - so if that context points at a remote or production daemon, the agent connects there too. Set `DOCKER_MCP_SERVER_HOSTS` (or `DOCKER_HOST`, or select a scoped context) before starting the server to pin the target(s) deliberately; with `DOCKER_MCP_SERVER_HOSTS` the `auto`/`local` endpoints are resolved and **pinned at startup**, so they can't drift if a context changes later. After startup, `context_use` only changes the CLI default for subsequent CLI-backed tools; SDK-backed tools keep using the daemon their pooled client connected to. **There is no runtime way to introduce or retarget a daemon at an arbitrary endpoint** - `system_reconnect` only *rebuilds* an already-configured host's client (to recover a wedged connection), it can't point it elsewhere; to add or change a daemon, edit `DOCKER_MCP_SERVER_HOSTS` and restart. This deliberately closes a trust-expansion vector (an agent can't move the root-equivalent boundary to an unvetted endpoint mid-session). `context_create(skip_tls_verify=True)` disables TLS verification for a context; use only against trusted local daemons.

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/docker_mcp/server.py

@@ -83,6 +83,7 @@ TOOL_CATEGORIES: dict[str, ToolCategory] = {
     "image_prune": ToolCategory.DESTRUCTIVE,
     "image_prune_builds": ToolCategory.DESTRUCTIVE,
     "image_load": ToolCategory.MUTATING,
+    "image_import": ToolCategory.MUTATING,
     "image_save": ToolCategory.MUTATING,  # can write a file on the server host (dest_path)
     "image_tag": ToolCategory.MUTATING,
     "image_history": ToolCategory.READ_ONLY,
@@ -136,10 +137,13 @@ TOOL_CATEGORIES: dict[str, ToolCategory] = {
     "swarm_unlock": ToolCategory.MUTATING,
     "swarm_unlock_key": ToolCategory.READ_ONLY,
     "swarm_join_tokens": ToolCategory.READ_ONLY,
+    "swarm_task_list": ToolCategory.READ_ONLY,
+    "swarm_task_inspect": ToolCategory.READ_ONLY,
     # plugins
     "plugin_create": ToolCategory.MUTATING,
     "plugin_inspect": ToolCategory.READ_ONLY,
     "plugin_install": ToolCategory.MUTATING,
+    "plugin_privileges": ToolCategory.READ_ONLY,
     "plugin_push": ToolCategory.MUTATING,
     "plugin_list": ToolCategory.READ_ONLY,
     "plugin_configure": ToolCategory.MUTATING,
@@ -486,7 +490,7 @@ _DOMAIN_BLURBS: dict[str, str] = {
     "volumes": "create/list/inspect/remove",
     "compose": "Docker Compose v2 (up/down/ps/logs/build/run/exec/...); CLI-backed",
     "stack": "Compose-on-Swarm (deploy/ls/ps/rm/services); CLI-backed",
-    "swarm": "swarm init/join/leave/unlock, join-tokens; manager node only",
+    "swarm": "swarm init/join/leave/unlock, join-tokens, cluster-wide task list/inspect; manager node only",
     "services": "Swarm services (create/scale/update/rollback/logs/tasks); manager node only",
     "nodes": "Swarm nodes (list/inspect/update/remove); manager node only",
     "secrets": "Swarm secrets; manager node only",

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/docker_mcp/tools/images.py

@@ -315,7 +315,8 @@ def image_load(data: bytes | None = None, from_file: str | None = None, host: st
     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. Pass exactly one of `data` (tarball bytes in band) or `from_file` (a path on the server host,
+    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.
 
@@ -333,6 +334,109 @@ def image_load(data: bytes | None = None, from_file: str | None = None, host: st
         return [i.attrs for i in _get_client(host).images.load(handle)]
 
 
+@tool()
+def image_import(
+    repository: str | None = None,
+    tag: str | None = None,
+    from_file: str | None = None,
+    data: bytes | None = None,
+    from_url: str | None = None,
+    from_image: str | None = None,
+    changes: list | None = None,
+    host: str | None = None,
+) -> str:
+    """
+    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`); ValueError 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 ValueError, 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` (ValueError without it — the daemon would otherwise silently drop the tag
+            and import untagged). Blank is also a ValueError, not a shorthand for the default: the
+            daemon would substitute `latest` without saying so
+        from_file - Path to a rootfs tarball on the server host (`~` expanded), read by the server's
+            user; FileNotFoundError if it is not an existing regular file; exactly one source
+        data - Rootfs tarball contents in band (base64-encoded by MCP, so prefer `from_file` for
+            anything but small archives); exactly one source
+        from_url - URL the daemon fetches the tarball from; exactly one source
+        from_image - Name of an existing image to import from, like a Dockerfile `FROM`; exactly one
+            source
+        changes - Dockerfile instructions applied to the new image, e.g. ['CMD ["/bin/sh"]']; only
+            CMD, ENTRYPOINT, ENV, EXPOSE, ONBUILD, USER, VOLUME and WORKDIR are supported. Parsed
+            as real Dockerfile syntax, so shell form is wrapped exactly as a Dockerfile would wrap
+            it (`CMD /bin/sh` is stored as `["/bin/sh","-c","/bin/sh"]`) — use the exec form
+            `CMD ["/bin/sh"]` to store a bare argv
+    returns: str - The daemon's raw newline-delimited JSON progress records; the final record carries
+        the new image id as its `status`
+    """
+    sources = {"from_file": from_file, "data": data, "from_url": from_url, "from_image": from_image}
+    supplied = [name for name, value in sources.items() if value is not None]
+    if len(supplied) != 1:
+        raise ValueError(
+            "Pass exactly one of `from_file`, `data`, `from_url` or `from_image` "
+            f"(got {', '.join(supplied) if supplied else 'none'})."
+        )
+    # A bare `tag` is refused rather than forwarded: the Engine returns early when `repo` is empty
+    # (moby's httputils.RepoTagReference), so the tag is silently dropped and the image lands
+    # untagged -- a caller asking for `:v1` would get no error and no tag. A blank `repository`
+    # reaches that same early return, verified against a live daemon (repository="", tag=... imports
+    # with RepoTags []), so it is refused rather than read as "no repository": passing one is never
+    # meaningful, and treating it as absent would reopen the silent drop through the back door.
+    if repository is not None and not repository.strip():
+        raise ValueError("`repository` cannot be blank; omit it entirely to import untagged.")
+    # A blank `tag` is the same silent substitution one step further on: `RepoTagReference` tests
+    # `tag != ""`, so an empty tag skips the WithTag path and falls through to `TagNameOnly`, which
+    # supplies `:latest`. The caller asked for one tag and would get a different one, with no error --
+    # so it is refused alongside a blank `repository` rather than left as the asymmetric case.
+    if tag is not None and not tag.strip():
+        raise ValueError("`tag` cannot be blank; omit it to accept the daemon's default of `latest`.")
+    if tag is not None and repository is None:
+        raise ValueError(
+            "`tag` needs a `repository` to attach to; pass `repository`, or omit `tag` to import untagged."
+        )
+
+    # The high-level ImageCollection has no import; these four are the documented low-level calls.
+    api = _get_client(host).api
+    common = drop_none(repository=repository, tag=tag, changes=changes)
+    if from_file is not None:
+        # `import_image_from_file` is a one-line delegation to `import_image(src=...)`, which sends
+        # the path as `fromSrc` whenever `docker.utils.is_file(src)` is false -- so a missing path
+        # (or a directory) is not an error but an instruction to the *daemon* to fetch that string
+        # over HTTP, in the daemon's network namespace. Verified against a live daemon:
+        # `from_file="127.0.0.1:9/rootfs.tar"` produced `Get "http://127.0.0.1:9/rootfs.tar"`.
+        # `docker import` itself opens the file and reports ENOENT, so this guard restores CLI
+        # parity and keeps `from_url` the only source that leaves the host.
+        path = host_read_path(from_file)
+        if not path.is_file():
+            raise FileNotFoundError(
+                f"No such rootfs tarball: {path}. Pass `from_url` to have the daemon fetch a URL, "
+                "or `data` to send the archive in band."
+            )
+        return api.import_image_from_file(str(path), **common)
+    if data is not None:
+        return api.import_image_from_data(data, **common)
+    if from_url is not None:
+        return api.import_image_from_url(from_url, **common)
+    return api.import_image_from_image(cast(str, from_image), **common)
+
+
 @tool()
 def image_save(
     id_or_name: str,

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/docker_mcp/tools/plugins.py

@@ -63,7 +63,8 @@ def plugin_install(remote: str, local_name: str | None = None, host: str | None
     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.
+    `vieux/sshfs:latest`. The daemon handles permission grants non-interactively — call
+    `plugin_privileges` first to see what host access the plugin is asking for.
     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
@@ -77,6 +78,30 @@ def plugin_install(remote: str, local_name: str | None = None, host: str | None
     return _get_client(host).plugins.install(remote, local_name=local_name).attrs
 
 
+@tool()
+def plugin_privileges(remote: str, host: str | None = None) -> list:
+    """
+    Ask the registry which host privileges a not-yet-installed plugin demands.
+
+    The review step before `plugin_install`, which grants these privileges non-interactively (the
+    daemon never prompts) — so this is the only chance to see what a plugin wants before it has it.
+    Worth checking for anything not already trusted: plugins routinely request host mounts, devices,
+    and elevated capabilities, and a granted privilege is host-level access, not container-scoped.
+    Reads the *remote* plugin from its registry and installs nothing; for the privileges of a plugin
+    already installed, read `Config` from `plugin_inspect` instead. Credentials come from
+    `system_login`, or from `~/.docker/config.json` if the host ran `docker login`. Raises if the
+    reference cannot be resolved in the registry.
+
+    args: remote - Registry plugin reference, `author/name:tag`; the `:latest` tag is optional and
+        is the default if omitted
+    returns: list - One dict per requested privilege ({"Name", "Description", "Value"}), e.g. Name
+        "mount" with Value ["/data"], or "capabilities" with Value ["CAP_SYS_ADMIN"]; empty if the
+        plugin requests none
+    """
+    # The high-level PluginCollection exposes no privileges call; this is the documented low-level one.
+    return _get_client(host).api.plugin_privileges(remote)
+
+
 @tool()
 def plugin_push(name: str, timeout_seconds: float = 300.0, host: str | None = None) -> dict:
     """

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/docker_mcp/tools/swarm.py

@@ -217,3 +217,64 @@ def swarm_join_tokens(host: str | None = None) -> dict:
     swarm = _get_client(host).swarm
     swarm.reload()
     return _read_join_tokens(swarm)
+
+
+# --- cluster-wide task queries ---
+#
+# Tasks are swarm objects, so these live here and share the `swarm` domain gate: a user who sets
+# DOCKER_MCP_SERVER_DISABLE=swarm expects everything named `swarm_*` to go with it. They are the
+# one part of this module that is not cluster lifecycle, and they read what `services.py` writes --
+# `service_ps` is the per-service view of the same task documents.
+#
+# Both stay on the low-level `client.api`: docker-py has no task collection at all (there is no
+# `client.tasks`), so these documented `APIClient` methods are the only public path.
+
+
+@tool()
+def swarm_task_list(filters: dict | None = None, host: str | None = None) -> list:
+    """
+    List tasks across the whole swarm, like `docker service ps` with no service to scope it.
+
+    The cluster-wide view of what is actually scheduled. `service_ps` covers one service and
+    `stack_ps` one stack, so answering "what is failing anywhere" or "what is running on this node"
+    through those means looping over every service; this is one call. Filter by `node` for a node's
+    workload (the CLI's `docker node ps`), `desired-state` to separate what should be running from
+    what is shutting down, or `service` for a single service -- for which `service_ps` is the
+    simpler call. Each task carries its full `Spec`, including the `ContainerSpec` (image, command,
+    env), so this returns much more per task than the `service-tasks://{id_or_name}` resource's
+    computed rollout summary. Read-only. Requires a swarm manager: any other node raises
+    `docker.errors.APIError`.
+
+    args:
+        filters - Filter dict; keys: id, name, service, node, label, desired-state
+            (running|shutdown|accepted); omit for every task in the cluster
+    returns: list - One full task document per task (ID, ServiceID, NodeID, Slot, Spec, Status,
+        DesiredState), the same shape `service_ps` returns
+    """
+    return _get_client(host).api.tasks(filters=filters)
+
+
+@tool()
+def swarm_task_inspect(id_or_name: str, host: str | None = None) -> dict:
+    """
+    Inspect a single swarm task, like `docker inspect --type task`.
+
+    For when you already hold a task reference -- from a `swarm_task_list` or `service_ps` row, a
+    service event, or an error message -- and want just that task. `swarm_task_list` returns the
+    same document for every task, so prefer it when scanning; this is the single-object fetch.
+    To reach the container behind a running task, read `Status.ContainerStatus.ContainerID` and pass
+    it to `container_inspect` / `container_logs` -- but note the container may be on another node,
+    where those tools cannot see it, and `service_logs` aggregates across tasks instead. Read-only.
+    Requires a swarm manager; raises `docker.errors.APIError` if the task does not exist, if a
+    prefix matches more than one task, or if this node is not a manager.
+
+    args:
+        id_or_name - The task id, an unambiguous id prefix, or the task's full name -- which is the
+            container-name form `<service>.<slot>.<taskid>` (`<service>.<nodeid>.<taskid>` for a
+            global service), NOT the shorter `<service>.<slot>` that `docker service ps` prints in
+            its NAME column, which does not resolve. The daemon tries full id, then full name, then
+            prefix, and rejects an ambiguous prefix rather than picking a match
+    returns: dict - Full task inspect payload, as `docker inspect --type task`. Carries no name
+        field of its own; compose one from `ServiceID`/`Slot` if you need it
+    """
+    return _get_client(host).api.inspect_task(id_or_name)

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/manifest.json

@@ -2,7 +2,7 @@
   "manifest_version": "0.4",
   "name": "docker-mcp-server",
   "display_name": "Docker MCP Server",
-  "version": "2.2.4",
+  "version": "2.2.5",
   "description": "Manage Docker through the Docker SDK for Python and the docker CLI: containers, images, networks, volumes, Compose, Swarm, Buildx, Scout, and OCI registries, exposed as MCP tools.",
   "long_description": "Manage one or more Docker daemons through your AI agent - containers, images, networks, volumes, Compose, Swarm, Buildx, Scout, and OCI registries, exposed as MCP tools.\n\nIt gives you much more control and flexibility than calling the Docker CLI directly: each operation is exposed as its own typed tool, marked read-only or not, with destructive actions separately flagged. This means a client can auto-approve reads while always confirming anything destructive, and the whole server can also be switched into a read-only or no-destructive mode as a blanket safeguard. Output is bounded rather than left to grow unboundedly - capped with a truncated flag instead of silently overflowing the agent's context.\n\nDiscovery is automatic for your local socket with no configuration required. Or point it at additional remote daemons over TCP, TLS, or SSH (and mark any of them read-only to monitor without the risk of accidental changes). It also surfaces logs and stats as resources for triage. Read-only / no-destructive / disabled-domain switches let you register a restricted tool surface.\n\nDocumentation is built for the agent, not just the person configuring it: an MCP resource exposes the Docker SDK reference in-session (with a tool-callable fallback for clients that can't read resources), and a live tool-catalog resource reports exactly what's registered under the current configuration. Each tool's own description names its nearest siblings and when to prefer each, states preconditions and side effects in plain language, and is honest about when it can still fail - so an agent can pick the right tool on the first try among 150+ options, not guess.\n\nAnswer questions like: 'why did my local container crash?', 'is my production system under memory pressure?', 'what differences are there between my staging and production systems?'\n\nRuns entirely on your machine and sends no telemetry - see the Privacy Policy.",
   "author": {

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "docker-mcp-server"
-version = "2.2.4"
+version = "2.2.5"
 description = "MCP server for managing Docker resources via the Docker SDK for Python"
 readme = "README.md"
 license = "MIT"

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/server.json

@@ -7,22 +7,22 @@
     "url": "https://github.com/L337-org/docker-mcp",
     "source": "github"
   },
-  "version": "2.2.4",
+  "version": "2.2.5",
   "packages": [
     {
       "registryType": "pypi",
       "identifier": "docker-mcp-server",
-      "version": "2.2.4",
+      "version": "2.2.5",
       "transport": { "type": "stdio" }
     },
     {
       "registryType": "oci",
-      "identifier": "ghcr.io/l337-org/docker-mcp-server:2.2.4",
+      "identifier": "ghcr.io/l337-org/docker-mcp-server:2.2.5",
       "transport": { "type": "stdio" }
     },
     {
       "registryType": "mcpb",
-      "identifier": "https://github.com/L337-org/docker-mcp/releases/download/v2.2.4/docker-mcp-server-2.2.4.mcpb",
+      "identifier": "https://github.com/L337-org/docker-mcp/releases/download/v2.2.5/docker-mcp-server-2.2.5.mcpb",
       "fileSha256": "0000000000000000000000000000000000000000000000000000000000000000",
       "transport": { "type": "stdio" }
     }

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/skills/l337-docker/reference/images.md

@@ -103,6 +103,23 @@ Always use `-o`/`-i`. A bare `docker save` writes a multi-hundred-megabyte tar t
 `export`/`import` (see `reference/containers.md`) flatten and lose all of it; they are not
 interchangeable.
 
+## Importing a flat rootfs
+
+```bash
+docker import rootfs.tar myorg/rootfs:v1                  # tar of a filesystem -> 1-layer image
+docker import --change 'CMD /bin/sh' rootfs.tar myorg/rootfs:v1
+docker import https://example.com/rootfs.tar myorg/rootfs:v1
+```
+
+- `import` takes a **filesystem** tar, `load` takes a `docker save` bundle. Feeding a save bundle to
+  `import` "works" and produces a useless image whose root is the bundle's own metadata files.
+- An imported image has an empty config - no `CMD`, `ENTRYPOINT` or `ENV` - so it will not run until
+  you set one. `--change` accepts only `CMD`, `ENTRYPOINT`, `ENV`, `EXPOSE`, `ONBUILD`, `USER`,
+  `VOLUME` and `WORKDIR`; `LABEL` is not among them, so an imported image cannot be
+  provenance-labelled at import time.
+- The URL form is fetched by the **daemon**, not by the shell - so it resolves in the daemon's
+  network namespace, which matters against a remote host.
+
 ## Removing and pruning
 
 ```bash

{docker_mcp_server-2.2.4 → docker_mcp_server-2.2.5}/skills/l337-docker/reference/swarm.md

@@ -82,6 +82,25 @@ docker service ps <svc> --no-trunc --format json | jq -rs \
 `--no-trunc` matters here - the `Error` column is where the real reason lives and it is truncated
 by default.
 
+### Tasks across the whole cluster
+
+There is no CLI command that lists every task in the swarm; `docker service ps` always needs a
+service. Fan out over the service list instead:
+
+```bash
+for svc in $(docker service ls -q); do
+  docker service ps "$svc" --no-trunc --format json
+done | jq -rs '.[] | select(.CurrentState | startswith("Running") | not)
+                   | [.Name, .Node, .CurrentState, .Error] | @tsv'
+docker node ps <node> --no-trunc            # the other axis: every task on one node
+docker inspect --type task <task-id>        # one task, full document
+```
+
+`docker service ps` prints `NAME` as `<service>.<slot>`, but `docker inspect --type task` will not
+resolve that form - pass the task `ID` from the same row instead. (The MCP server exposes the
+cluster-wide read directly as `swarm_task_list`, with `node`, `service` and `desired-state`
+filters.)
+
 ### Creating and updating
 
 ```bash