Each dedicated tool has a clearly bounded purpose (docker_ps vs docker_logs vs docker_exec, sys_snapshot vs service_status vs http_probe), and exec explicitly instructs the agent to prefer a specialized tool. Minor overlaps remain: exec can do anything its peers do, docker_exec mirrors exec semantics on a container, and backup_file duplicates the automatic backup that file_write already performs on overwrite.

The dominant pattern is domain_action (file_read, file_write, docker_ps, docker_exec, docker_logs, http_probe, xui_api), which reads predictably and groups related tools by prefix. Deviations are small but real: exec is a bare verb, and backup_file inverts the order (verb_resource) relative to the rest.

Eleven tools is squarely in the well-scoped band for a remote-ops server, and each one maps to a recurring day-to-day task rather than a redundant variation. The broad exec escape hatch keeps the specialized set from needing to grow further.

Read/write/backup for files, container inspection and exec, system and service diagnostics, egress probing, and panel API access cover the core remote-ops lifecycle with no dead ends. Gaps are minor: no directory listing, file copy/move, or container lifecycle controls (restart/stop), all of which must fall back to exec.