mobile_swipe

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

With no annotations, the description carries the full burden. It discloses the action and the coordinate unit ('device pixels'), plus the JSON return type, but does not mention swipe duration/speed, coordinate origin, or failure behavior such as an unsupported device state.

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 description is short and front-loaded: the action sentence comes first, followed by a compact Args block and a Returns line. Every sentence earns its place, and there is no filler, though the argument list could be formatted more cleanly.

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 simple gesture tool, the description covers the needed inputs and a basic return expectation, but it omits a few operational details an agent may need: coordinate origin, whether the screen must be unlocked/app in foreground, and any error or timeout semantics. The presence of an output schema reduces the need to document the return shape, but behavior gaps remain.

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, and it does: it explains all five parameters, identifies serialno as a device serial from list_devices, and clarifies that x1/y1 and x2/y2 are start/end coordinates in device pixels. It adds real meaning beyond the bare integer/string schema, though coordinate origin and bounds are unspecified.

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 opening line, 'Swipe from one point to another,' states a specific action and resource, and the coordinate parameters make the gesture unambiguous. It is clearly distinct from sibling tools like mobile_tap, mobile_double_tap, and mobile_long_press, though it does not explicitly call out that distinction.

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?

No guidance is given about when to use a swipe versus tap, long-press, or scroll-like alternatives. The only contextual instruction is that serialno comes from list_devices, but there is no mention of screen-on/foreground-app prerequisites or when not to use this tool.

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