scroll

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses target-resolution fallbacks (largest scrollable element, screen centre only when no UI tree exists), which is real behavioral context. It does not mention what happens at list boundaries, whether the gesture settles before observing, or that the default 'observe' returns a diff rather than a full tree – that last point lives only in the schema.

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?

One front-loaded sentence with the direction semantic up front and target fallback in a parenthetical. Dense but every clause carries information; the nested parenthetical is slightly hard to parse but not wasteful.

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 6-parameter, no-annotation, no-output-schema tool, the description covers target selection and direction well. It leaves the observation/return behavior entirely to the schema and says nothing about boundary conditions or device serial implications, so an agent calling it blind has minor gaps.

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 83%, so the baseline is 3, but the description adds genuine meaning for the two most important semantics: the direction mapping and what 'index' selects when omitted. That added context for the default/fallback behavior goes beyond the schema's '[ref] of the scrollable element'.

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 specific verb and resource ('scroll the content in a direction') and immediately clarifies the direction semantic ('down = reveal content below'). It also spells out target resolution (given index, else largest scrollable element, else screen centre), which is more than the name conveys. It does not distinguish itself from the sibling 'swipe', which is the obvious nearby alternative.

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 implied by the direction/target explanation, but there is no explicit guidance on when to reach for scroll rather than swipe or press_key, nor any prerequisite or exclusion notes. An agent can infer the intent but must decide on its own between this and the swipe sibling.

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