qemu_mouse_move

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

All annotations are false, so they carry no real information and the description bears the disclosure burden. The description does add context beyond annotations: the operation travels over QMP, coordinates are absolute, and the target VM must already be running. It does not, however, disclose the primary side-effect (injecting an input event that visibly moves the guest cursor) or any error/edge behavior. Nothing in the description contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single nine-word sentence that leads with the verb and packs the three essential qualifiers ('absolute', 'QMP', 'running') with zero filler. Every word earns its place and the most decision-relevant information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter tool with no output schema and neutral annotations, the description covers the essentials but leaves two gaps an agent must resolve on its own: how the 0-65535 absolute coordinate space maps to the actual guest display, and which sibling should be chosen instead (qemu_mouse_click versus this move tool, or the generic mouse_move). These gaps are non-trivial given the sibling list contains nine mouse-related tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67%: x and y are documented as 'Zero-based physical screen coordinate' with 0-65535 bounds, but vm_id has no description in the schema. The description adds the 'absolute' qualifier, which clarifies the coordinate semantics beyond what the schema states, but it does not explain how the 0-65535 space maps to the guest display, and it contributes nothing for the undocumented vm_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Send') with a clear resource ('absolute QMP mouse coordinates to a running QEMU VM'), stating exactly what the tool does. The 'absolute' and 'QMP' qualifiers meaningfully differentiate it from the generic mouse_move sibling, though it does not explicitly distinguish itself from qemu_mouse_click, which is the closest competing sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'to a running QEMU VM' implies a prerequisite (the VM must be running before this tool is valid), and 'absolute' implies it is not for relative pointer movements. However, the description offers no explicit when-to-use vs. when-not-to-use guidance and names no alternatives, leaving the agent to infer placement among nine mouse-related siblings like qemu_mouse_click, mouse_drag, and mouse_scroll.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.