Hover

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

Annotations only declare readOnlyHint=false and openWorldHint=false; the description adds the useful behavioral fact that hovering can open menus/tooltips. However, it does not say how the input is dispatched (pointer/mouse event sequence vs single move), whether the pointer position persists for a subsequent click, or whether it waits for the revealed UI to settle — all relevant for a mutation-flagged interaction tool.

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 sentence, front-loaded with the action, with the two targeting modes and the expected outcome packed in and no filler. Every clause carries information.

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?

With no output schema and four optional parameters, the description covers the target selection but leaves open what the tool reports back (nothing? coordinates hovered? revealed elements?) and the post-hover state, which matters for chaining a click after a hover-revealed menu. Adequate but with clear gaps for a UI-interaction primitive.

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 coverage is 100%, so 3 is the baseline, but the description adds real meaning by framing 'ref' and 'x/y' as two alternative targeting modes (element vs viewport point), which the schema's flat property list does not convey. It still omits precedence when both ref and x/y are supplied, which is why it is not a 5.

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?

States a concrete verb (moves the mouse over) plus the resource/targeting modes (element by ref or viewport point), and notes the observable effect (hover menus, tooltips). That distinguishes it from click, drag, and press_key without naming them, but it never explicitly routes away from those siblings, so it stops short of a 5.

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?

Usage is only implied by the phrase 'triggering hover menus and tooltips' — an agent can infer 'use this to reveal hover-only UI,' but there is no explicit when-to-use, no when-not (e.g., for activation use click), and no prerequisite or sequencing guidance such as whether to call wait_for afterward for lazily rendered menus.

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