tap

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

Annotations provide openWorldHint=true and readOnlyHint=false, but no destructiveHint guidance. The description adds nothing about what happens on tap (e.g., does it trigger a down+up event, does it require display on, any coordinate system caveats). With readOnlyHint=false already signaling mutation, the description misses the opportunity to clarify coordinate origin (top-left?) or require the screen to be on. It's neutral but not contradictory.

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 sentence, zero waste. Every word earns its place. This is an appropriately minimal description for a simple coordinate-tap operation.

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?

There's an output schema present, and the parameters are simple coordinates at 100% schema coverage, so the description carries less burden. However, given the tool operates on a physical device screen, it should clarify coordinate origin (top-left corner), whether the screen must be active/on, and how coordinates map to device resolution versus display scaling. These are meaningful gaps for a device-control 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?

Schema coverage is 100% and only 2 required params (x, y). The schema already describes 'X coordinate' and 'Y coordinate' clearly. The description adds no parameter detail beyond what the schema provides, but with 100% coverage and simple coordinate params, the description's silence is acceptable. The serial param is undocumented in the description, but it's optional and self-explanatory as a device identifier.

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 'Tap at the specified screen coordinates' clearly states the verb (tap) and resource (screen coordinates). It's straightforward and distinguishes from siblings like swipe, long_press, and drag_drop since 'tap' is specific. However, it doesn't explicitly contrast with similar actions like ui_tap_element (which taps an element rather than coordinates), leaving slight ambiguity about when to use coordinate-based tapping.

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 on when to use this vs alternatives like ui_tap_element or app interactions. The description doesn't mention that this operates on raw screen coordinates versus on UI elements, nor does it note prerequisites like screen-on state or that coordinates must be within the device display bounds. For a tool with 44 siblings including ui_tap_element, this is a notable gap.

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