Most tools target a distinct action+resource, and the async command trio (execute_command_async, get_command_status, get_command_output, wait_for_command) is carefully differentiated in the descriptions. The only real overlap is list_vms vs list_running_vms (the latter is just a filtered view) and get_vm_state vs get_vm_info (state is a subset of info), plus several closely-related power tools whose distinctions are at least spelled out.

All 27 tools use consistent snake_case verb_noun form (list_vms, get_vm_info, start_vm, poweroff_vm, write_guest_file, cancel_command). Even the async variant (execute_command_async) and paging helpers follow the same predictable pattern.

At 27 tools the surface is heavy for a VM manager, split across four sub-domains (VM lifecycle, command execution, guest files, host/info). Each tool is individually justified and not obviously padded, but a few (list_running_vms, get_vm_state) could be folded into broader tools to slim the set.

Power/lifecycle control of existing VMs, guest command execution, and guest file CRUD are well covered, but there is no create/register/clone VM, no unregister/delete VM, no snapshot operations (take/restore/list), and no way to modify VM configuration (CPU, memory, network). An agent asked to provision or snapshot a VM will hit a dead end.