android_tap

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action and does not reveal any side effects, prerequisites (e.g., screen on, app foreground), or whether the tap is synchronous or asynchronous. The agent has no information about what happens after the tap or how success is indicated.

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 a single concise sentence with no filler or redundant words. It is front-loaded with the action verb and delivers the purpose directly, which is ideal for a simple tool. Nothing needs to be cut.

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?

The tool is simple, but the description omits important context for correct usage, such as the coordinate system origin (top-left corner is assumed), behavior on invalid coordinates, and the role of deviceId when multiple devices are connected. It also does not distinguish from android_click_element for element-based interactions. Given the rich sibling set, the description is incomplete for an agent that must choose the right interaction tool.

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?

The input schema already describes all three parameters (x, y, deviceId) with clear definitions and 100% coverage. The description adds nothing beyond restating that the tap is at 'specific (x, y) pixel coordinates', which is essentially redundant with the schema. Baseline 3 is appropriate because the schema handles the semantic load.

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 the action verb 'Tap' and the resource 'specific (x, y) pixel coordinates on the Android device screen', making the tool's purpose clear and unambiguous. It is distinct from sibling tools like android_click_element (element-based) and android_swipe (gesture-based), so an agent can tell it apart without further explanation.

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 provided on when to use this tool versus its alternatives. The description does not mention that it is for coordinate-based taps rather than element-based clicks, nor does it clarify when deviceId is needed. An agent would have to infer usage context from the schema alone.

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