human_scroll

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds useful behavioral constraints: wheel deltas are in Windows units, must be multiples of 120, and no pixel/line inference is performed. It does not describe what application state may change from scrolling or how the target hwnd is affected, which is a gap even with annotations present.

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?

The two-sentence description is front-loaded and has no filler. 'No pixel/line inference' is a meaningful constraint rather than repetition. It is efficient, though its brevity contributes to the larger completeness gaps.

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 non-idempotent, destructive scroll operation with five parameters, a nested pause_policy object, and no output schema, the description is too sparse. It says nothing about hwnd targeting, axis behavior, threshold_px, pause_policy tuning, or what the caller should expect after scrolling. The annotations cover safety hints but not operational completeness.

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%, so the description must compensate, but it only explains delta semantics: Windows units, multiples of 120 up to 1200. It leaves hwnd, axis, threshold_px, and the entire nested pause_policy object undocumented in both schema and prose. This is inadequate for a five-parameter tool with a nested object.

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 states a specific verb and resource: 'one explicit wheel operation'. The Windows-unit and 120-multiple constraints make the core action unambiguous. It does not differentiate this scroll tool from siblings such as human_mouse_move or human_mouse_drag, 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?

There is no guidance on when to use human_scroll versus alternatives like human_mouse_move or human_mouse_drag. The description also omits prerequisites, such as whether the target window must be active or focused. Usage is only implied by the tool name and the phrase 'one explicit wheel operation'.

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