tap

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

No annotations are provided, so the description carries the full behavioral burden and falls well short. It does not mention that a device must be connected, whether the tap is relative to the current screen orientation or the physical display, or which device is targeted when the serial parameter is omitted.

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 short, front-loaded sentence with zero padding — but the terseness here reflects under-specification rather than disciplined concision. It is efficient in size but does not earn its brevity with required detail.

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?

An output schema exists, so return-value explanation is not required. Still, for a 3-parameter device-interaction tool with no annotations, the description omits device targeting, connectivity prerequisites, and differentiation from tap_element, leaving real gaps.

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% and the parameters have only bare titles. The description does add one genuinely useful semantic: x and y are pixel coordinates. But the optional 'serial' parameter is never explained, so an agent has no idea how to target a specific device among several.

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 and resource with the operand form: 'Tap the screen at pixel (x, y).' An agent immediately knows this is an input-injection action. However, it does not differentiate itself from the sibling tap_element, which also taps, so the boundary between the two is left to inference.

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?

There is no when-to-use guidance at all. With siblings like tap_element, long_press, swipe, and drag, the description never says when raw pixel tapping is preferable to element-based tapping or when it should not be used.

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