console_click

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's job is to explain consequences — e.g. that a click lands inside the guest UI and can trigger real, irreversible actions. It says nothing about that risk, nor about required console session state, coordinate origin, or coordinate units, so it adds no behavioral context beyond 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?

Two short, front-loaded sentences with no filler; the primary action comes before the optional positioning step. It is efficient, though brevity here comes at the cost of the missing details noted elsewhere.

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?

An output schema exists, so return values need not be described, and the four parameters are few and mostly simple. What is still missing for a destructive interactive tool is console session prerequisites and the meaning/units of the guest-display coordinates. Note: the rubric's scoring for this dimension is applied leniently here because an output schema is present and the parameter set is small; the core gap remains the destructive-action and session-state context.

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 0%, and the description partially compensates by naming the three button values and clarifying that x/y are guest-display coordinates applied before the click. It still leaves vm_name unexplained, gives no units or origin for x/y, and does not note that x and y must be supplied together or that button defaults to left.

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?

It states a concrete verb (click) and the selectable resource (left/right/middle mouse button), but it never distinguishes itself from its close siblings console_mouse_buttons and console_mouse_move, which appear to cover overlapping ground. An agent cannot confidently pick console_click over those without guessing.

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?

There is no 'use this when' guidance, no prerequisites (must the console be connected? must the guest display be active?), and no mention of the sibling tools that perform similar mouse operations. The only implicit guidance is the word 'Optionally', which hints that x/y are unnecessary.

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