Related Servers

The eight monitor_* tools overlap heavily (get_system_status already returns CPU, memory, disk, network and processes, duplicating get_resource_usage, get_performance_metrics, get_memory_info, get_cpu_info, get_network_info and get_process_info), and host_ops.get_system_info overlaps again. container_ops restart_container/container_logs/container_stats also collide with compose_restart/compose_logs/compose_ps for the same underlying services. The multiplexer design (file_ops, dir_ops, search_ops, container_ops, infra_ops, host_ops) further forces an agent to pick a tool and then an operation, adding a second layer of ambiguity.

Most names are snake_case and readable, and the monitor_get_* prefix is consistent, but the set mixes two paradigms: single-action tools (compose_up, compose_down, server_shutdown) alongside six generic *_ops multiplexers that hide dozens of operations. The compose family is split across two conventions (compose_restart vs container_ops restart_container; compose_ps vs container_ops list_containers), so the pattern is not fully predictable.

24 top-level tools is already heavy for a filesystem server, and six of them are multiplexers that expand to roughly 90 operations, so the effective surface is far larger than a filesystem domain warrants. Docker compose, container lifecycle, image/network/volume infra, host introspection and system monitoring are well outside the stated purpose and crowd out the core file tools.

Core filesystem coverage is strong: read/write/edit/append/touch/delete/move/copy/exists/info/hash/undo plus full directory management and a solid search/analysis set, with no obvious dead ends for normal file workflows. Gaps are minor (no permissions/chmod, symlink handling, or file watching), though the Docker/host tooling is broad and shallow rather than deep CRUD for a filesystem server.