appium_mobile_press_key

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

Annotations already signal a non-read-only operation, so the description only needs to add behavioral context. It adds platform-specific key behavior and implies navigation side effects via key names, but it does not explicitly state effects like leaving the current screen (HOME/APP_SWITCH) or changing volume, nor does it mention long-press behavior.

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 sentence delivers the core action and platform scope with no filler or repetition. It is front-loaded and every phrase earns its place.

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 input schema fully documents all four parameters, including platform restrictions and keyCode precedence, so the brief description plus the schema gives an agent what it needs for a simple key press. The main missing piece is relationship guidance to sibling input tools, which is already captured under usage guidelines.

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 100%, so the baseline is 3 and the schema already documents key, keyCode precedence, sessionId, and isLongPress. The description only echoes a subset of key-to-platform mappings and adds no new meaning beyond the schema.

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 opens with the specific action 'Press' and identifies the exact resources: navigation keys (BACK, HOME, APP_SWITCH) on Android and physical buttons on iOS/tvOS. This clearly distinguishes the tool from sibling input tools like appium_mobile_keyboard and appium_gesture without needing to open the schema.

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 guidance about when to choose this tool over alternatives or when not to use it. The only context is platform coverage ('on Android' vs 'on iOS/tvOS'), but the description never names a sibling like appium_mobile_keyboard or appium_perform_actions or gives a selection condition.

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