Send Android key

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

The description mentions 'capability-gated press options', hinting that certain actions may be unavailable depending on device capabilities. Annotations are minimal (all false), so the description adds some behavioral context. However, it does not disclose error handling, side effects, or failure modes.

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 sentence that is concise and front-loaded with the main action. It contains no fluff, but given the tool's complexity with 6 parameters, additional structured information (like a brief list of keys) could be beneficial without sacrificing conciseness.

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 description covers the basic purpose but lacks completeness for an agent to correctly differentiate from 30+ sibling tools. It does not mention the key format or common use cases. With an output schema assumed, it doesn't need to explain return values, but it should still provide enough context for appropriate tool selection.

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?

With only 33% schema description coverage, the description partially compensates by clarifying that 'key' can be symbolic or numeric, and that 'source' defaults to gamepad. However, it does not explain the 'action' enum values, 'durationMs', or 'displayId' beyond what the schema provides. More detail would be needed for full clarity.

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 clearly states the tool sends Android keys, specifying 'symbolic or numeric' and 'gamepad source'. While it mentions 'gamepad source' as default, it doesn't explicitly differentiate from sibling tools like mobile_input_key_combination or mobile_input_text. However, it clearly indicates the core action of sending a key.

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?

The description lacks any guidance on when to use this tool versus alternatives. It does not mention when to prefer this over mobile_input_key_combination or mobile_input_text, nor does it state prerequisites or conflicts. No when-to-use or when-not-to-use information is provided.

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