Skip to main content
Glama

aua_long_press

Trigger a long press on an Android app element via selector or display coordinates for 0.5–3 seconds, with optional wait and result observation.

Instructions

Long press once by selector OR x/y display pixels for duration seconds (0.5..3). Supports wait_for and observe. Inspect uncertain results; no replay.

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
visualNo
observeNonone
durationNo
selectorNo
wait_forNo
variationNo
observation_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so mutability and non-idempotency are covered. 'No replay' and 'inspect uncertain results' add a modest verification warning, but nothing about failure behavior, blocking, or what an uncertain outcome looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short clauses, front-loaded with the verb and targeting modes, then capability flags, then a caution. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with zero schema description coverage, no output schema, and opaque nested objects (visual/LocateArgs, variation, observation_id), the description explains only the targeting modes and duration. An agent cannot infer what visual matching, variation, or observation_id do from this text.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description must carry the load, and it does cover the key semantic decision (selector versus x/y coordinates, mutually exclusive via 'OR') plus the duration range. It leaves visual, variation, observation_id, the observe enum values and all Selector fields entirely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Long press once by selector OR x/y display pixels', with a duration parameter. The 'once' phrasing implicitly separates it from aua_tap and aua_double_tap, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Inspect uncertain results; no replay' gives post-call guidance, but the description never says when to choose a long press over aua_tap, aua_drag or aua_swipe, nor when selector-based targeting should be preferred over raw coordinates.

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