MCP Docker problems and fixes

Check the selected daemon and the account’s socket, pipe or network access. Set DOCKER_HOST for the intended daemon, then repeat mcp-docker cli system info. Unix sockets and plaintext TCP/HTTP are supported; HTTPS and SSH are refused, and named pipes require Windows. An empty setting uses local defaults.

Check the daemon version and the operation that failed; a successful connection check does not prove API compatibility. Use an approved compatible daemon or MCP Docker build. Normal startup does not negotiate automatically, and this executable has no DOCKER_API_VERSION override.

Check the image or destination registry against ALLOWED_REGISTRIES. Choose an approved registry, or have the deployment owner add an approved hostname and restart the server. Private-registry authentication is supplied separately with each pull or push; credentials do not bypass the registry restriction.

Inspect existing workloads in the session before changing MAX_CONTAINERS_PER_SESSION (default 100). Remove only disposable workloads, or configure the approved higher limit before startup. cleanup_session can delete tracked volumes, so use it only for intended teardown.

Inspect Docker state before repeating a change: a timeout can leave a container, image or completed build behind. Served requests have a fixed 60-second deadline even when the operation allows longer. For a running container, stop it separately only when that is intended; a wait timeout does not stop it.

Check the current tool arguments and the full error. Use container_id, host_path and container_path for copy, and remove unsupported extra fields. A missing path does not establish that the container is gone; correct the source path or create the intended destination directory before retrying.

Check the requested mount type and both paths. Current creation supports bind mounts only; use type:bind with an approved daemon-host source and container destination, or a separately approved administration route for other attachment types. Creating a named volume alone does not attach it.

Check which resources should be retained. Disconnect does not remove workloads, and session reclamation only releases tracking. Remove disposable resources explicitly from their owning context; inspect cleanup errors and preserve valuable volume data. Images need separate removal because session cleanup does not remove them.

Check the owning context and whether recovery is intended. Use the original session where available, or coordinate container adoption through MCP. Adoption can share control with the original owner; it is not an exclusive transfer. The CLI cannot bypass MCP ownership, and networks and volumes have no adoption action.

Check USE_MEMORY_STATE, the configured state location and saved errors. Memory mode loses adoption between calls; unreadable state or concurrent writers can also lose records. Preserve resource IDs and state, serialize recovery, then verify the container before re-adopting. Missing tracking does not mean the data was deleted.

Check mcp-docker help or mcp-docker cli <resource> help; --help is unavailable. Use MCP tools for unsupported CLI operations. Event and statistics CLI paths can fail before producing results; use stream_events or container_stats with a bounded observation window.

Check the live tool catalog. Use container_control with an action and adopt with action:container; old flat names are obsolete. Suggestions to run CLI adopt or cleanup are also stale: use MCP adoption and explicit removal tools, or the supported CLI resource removal commands.

Check the response body, especially status and checks.runtime.healthy. Correct daemon access, then verify a harmless Docker operation. A degraded result still returns 200, and the state check does not prove that the state file is writable.

Check for an invalid DOCKER_HOST setting. Correct it for the intended daemon, or unset an accidental override, and retry the harmless command. No resource changes are needed to diagnose this startup failure.