No user-submitted related servers found.
Scored across 42 tools
Most tools have a clearly distinct resource+action target: listing (docker_images, docker_networks, docker_volumes, docker_ps), lifecycle (docker_run, docker_create, docker_remove, docker_prune), and stack operations (docker_stacks vs docker_stack_status/file/config/action/write/logs) are well separated. The main friction is the deliberate catch-alls docker_cli and server_run, which overlap every other tool and could pull an agent away from the specific, safer tools; docker_stack_logs vs docker_logs and docker_tag_image vs docker_build are also easy to confuse at a glance.
Names are uniformly snake_case and follow a clear two-level prefix scheme (docker_* for Docker object operations, server_* for host operations), with list tools consistently using bare nouns and state-changing tools using a verb or an explicit action parameter. Minor deviations exist: docker_ps instead of docker_containers, and docker_create/docker_remove take a 'kind' argument while other tools are single-purpose, but nothing is ambiguous to read.
42 tools is a very large surface for one server, well above the range where each tool clearly earns its place. The breadth (containers, images, networks, volumes, compose stacks, files, host shell, systemd, packages, jobs) explains the size, but the escape hatches docker_cli and server_run could absorb several narrow tools (docker_tag_image, docker_copy, docker_pull_image) and reduce the count substantially.
Coverage is unusually thorough: full container/image/network/volume lifecycle, compose stack create/update/up/down/logs, file CRUD plus edit, host inspection, systemd, packages, background jobs and power control. Only peripheral gaps remain (image push, registry auth, docker events, network connect/disconnect for existing containers), and those are explicitly reachable via docker_cli and server_run, so no real dead ends.