Perform a single swipe gesture on an Android device to navigate screens or reveal content. Specify direction, optional display region, and observe the result for next-step context.
Perform one swipe. Direction is finger motion: up usually reveals later rows. Use display-pixel region if needed, observe for next-step context. No automatic retries.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | ||
| observe | No | none | |
| duration | No | ||
| direction | No | up | |
| observation_id | No |
Changes observed during successful MCP inspections.
v0.2.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=false, openWorldHint=true and idempotentHint=false. The description adds genuinely new behavioral context with 'No automatic retries' and the observation-for-next-step hint, but says nothing about what the swipe affects on screen, failure modes, or what the observation_id does.
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?
Four short sentences, front-loaded with the core action and no filler. The telegraphic style ('observe for next-step context') is slightly terse at the cost of clarity, but nothing is redundant.
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 five-parameter interaction tool with no output schema and no parameter descriptions, the description should explain duration units/bounds and the role of observation_id. It covers only part of the surface, leaving an agent to infer how to correlate an observation with a prior call.
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 carries the full burden. It loosely clarifies direction (finger motion, up = later rows), region (display-pixel coordinates) and observe (next-step context), but duration and observation_id are left entirely unexplained, leaving two of five parameters with no semantic guidance anywhere.
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: 'Perform one swipe', which is more precise than the bare tool name and clarifies that a single gesture is executed. It does not differentiate from siblings such as aua_screen_action or aua_tap, which could plausibly also produce gesture input, 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?
It offers usage hints ('up usually reveals later rows', 'observe for next-step context') that help an agent pick a direction and decide whether to request observation. It never states when to prefer this over aua_screen_action or aua_batch, nor any preconditions, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.