Related Servers

Most tools target a distinct resource+action (container_*, image_*, network_*, volume_*), but at 165 tools there are several genuinely overlapping-purpose families: four log tools, three registry/manifest inspection tools, two tag-listing tools (registry_tags vs hub_tags), and five wait tools. The descriptions are exemplary at cross-referencing siblings and stating each tool's exact scope, which compensates substantially, but an agent can still realistically misselect within the registry and log clusters.

The dominant `domain_action` snake_case pattern is applied consistently across ~17 domains (container_run, image_remove, volume_prune, service_scale, secret_create, buildx_build, registry_tags). Minor deviations are mostly CLI-faithful (`compose_cp`, `compose_ps`, `swarm_init`, `image_tag`) plus noun-style scout_*/hub_*/registry_manifest, which are predictable rather than chaotic.

165 tools is far beyond any reasonable agent surface — roughly three times the rubric's 'extreme mismatch' threshold. The scope is genuinely broad (Docker engine + compose + swarm + buildx + registries + scout) and the set is well-organized, but the container_*/compose_*/service_* triads triple near-identical operations and the server even ships meta-tools (tool_list, docs_lookup) to help agents navigate its own size.

This is effectively the entire Docker CLI surface: full lifecycle coverage for containers, images, networks, volumes, compose, swarm/services/stacks, secrets, configs, plugins, buildx, registries, and Scout — each with create/read/update/delete or equivalent. The only gaps are trivial (no standalone container_port or docker attach) and each has a documented workaround via container_inspect, so workflows have no dead ends.