The day-to-day work is all here — bring a container up, read its logs when it misbehaves, drop the volume afterwards — and the compose prompt shows you its plan before it changes anything. Docker is not a sandbox, so what the agent can reach is whatever the daemon can reach; review what it proposes to create.
An MCP server over the Docker daemon, local or remote. Its tools cover containers, images, volumes and networks, and a guided compose prompt puts a natural-language plan in front of you before anything is created.
- Containers listed, created, started, stopped, removed and recreated — list_containers, create_container, start_container, stop_container, remove_container, recreate_container
- A container run from an image in a single call with run_container
- Logs pulled from the container that is misbehaving through fetch_container_logs, or read as a resource by container id or name
- Live stats for a running container, also addressable as a resource rather than a tool call
- Images through list_images, pull_image, build_image, push_image and remove_image
- Volumes through list_volumes, create_volume and remove_volume, and networks through list_networks, create_network and remove_network
- A docker_compose prompt that takes a project name and a description, writes a plan, and applies it only after you agree — and on a later chat, reports the state of everything created under that project name
- Privileged flags left out on purpose: --privileged and --cap-add or --cap-drop are not supported
Uv, and a Docker daemon it can reach. It uses the environment's usual Docker settings, so the local daemon works with nothing configured, and DOCKER_HOST set to an ssh:// URL points it at a remote engine. Running it as a container instead means mounting /var/run/docker.sock so it can still reach the daemon. Keep secrets out of the container definitions you describe: whatever you type goes to the model.
One command — uvx mcp-server-docker