adb_scroll

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

No annotations exist, so the description carries the full disclosure burden, yet it says nothing about the default scroll amount, whether a device must already be connected, whether the call blocks until the animation finishes, or what happens on failure. 'Scroll the screen' does convey that input is injected into the device, but that is the only behavioral signal available.

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 with the action front-loaded and no filler; the qualifying clause is the only extra and it does work. It is on the terse side for a tool with an undocumented default amount, but nothing in it is wasted.

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 only three parameters, no annotations, and no output schema, the description is barely sufficient: it covers the core action but omits the default amount behavior and any device-connection precondition. An agent could call it correctly for the required direction, but would be guessing at the optional parameters' defaults.

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 67%: the amount range, the device selector form, and the direction enum are all documented in the schema already. The description adds no extra meaning to any parameter (no default for amount, no effect of combining a direction with a small vs large amount), so it does not exceed the baseline.

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 (scroll) and resource (the screen) plus the four supported directions, which is unambiguous. It does not name adb_swipe, the closest sibling, so the agent has to infer the distinction from the phrase 'without working out coordinates' rather than an explicit routing statement.

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 clause 'without working out coordinates' implies the usage condition (use this instead of a coordinate-based gesture) but never names adb_swipe as the alternative nor states when a coordinate-driven swipe would be preferred. Usage is implied rather than spelled out.

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