Tap, type or press a key

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is covered. The description adds genuinely useful behavior not in annotations: the coordinate frame is screenshot pixels at maxDimension 0. However, it omits key operational facts, notably whether tap, text, and key can be combined in one call and what happens if none is supplied (zero required parameters), plus whether it returns any confirmation.

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?

A single front-loaded sentence that names the tool class first, then the three modes in order, with the essential coordinate-frame caveat in a tight parenthetical. No filler or restatement of the title.

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 low-level input-injection tool with a nested object parameter, no output schema, and 0 required parameters, the definition covers the modes and coordinate frame but leaves out the exclusive-or semantics of tap/text/key and any result behavior. Adequate to call it in the happy path, but an agent could construct an ambiguous or empty call with no warning.

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 only 25% (only 'serial' is documented), so the description must compensate, and it does: it explains the pixel coordinate space for tap.x/tap.y, that text goes to the focused field, and that key accepts keyevent names or numeric codes like KEYCODE_BACK / 4. These are meanings the schema cannot convey on its own; only the mutual exclusivity of the three modes remains unaddressed.

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+resource ('Low-level input') and enumerates the three distinct operations the single tool supports: tap, type, and keyevent. It clearly distinguishes itself from the sibling device-management tools, but does not name a comparable alternative (there is none in the sibling list), so it falls just 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?

Usage is implied through the reference to android_screenshot ('pixels from android_screenshot at maxDimension 0'), which tells the agent to take a screenshot first and read coordinates from it. There is no explicit statement of when not to use it, no note that the three modes are mutually exclusive, and no guidance on which of tap/text/key to prefer for a given goal.

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