Skip to main content
Glama

long_press

Perform a long-press on an Android UI element by index, text, or id, or on a screen coordinate (x, y), to trigger context menus or press-and-hold actions.

Instructions

Long-press an element (by index, text or id) or a screen point (x, y).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoScreen x (with y), from a screenshot or get_ui
yNo
idNoMatch resource id / Compose testTag
textNoMatch element text or content description (case-insensitive)
exactNoRequire the whole text/id to match instead of a substring
indexNoElement [ref] from get_ui or a change report
serialNoadb serial; optional when exactly one device is connected
observeNoWhat to return after the action: changes (default: only what changed since you last saw the screen, full tree on a new screen), ui (full tree), screenshot, both (tree + screenshot), nonechanges
settle_msNoWait before observing
occurrenceNoWhich match to use when several match (0-based)
duration_msNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden and discloses nothing: no mention of mutation side effects, that reverting requires another action, or how the result is returned. The observe/settle_ms schema descriptions carry the disclosure work, but that is not the description's contribution.

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

Conciseness4/5

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

A single front-loaded sentence with no filler, and the two targeting paths are presented in parallel. It is slightly under-specified rather than wasteful, since no timing or device context is mentioned.

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?

An 11-parameter device-interaction tool with no annotations and no output schema needs more: device/serial selection, press duration behavior, and what the default 'changes' observation returns are all left unexplained. The description covers only target selection for a tool whose complexity is much broader.

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?

Schema coverage is 82%, so the structured fields already explain most parameters, including the observe modes and settle_ms. The description only restates the identifier parameters and says nothing about duration_ms (which has no schema description) or the serial/device targeting, adding no meaning beyond the schema.

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 (long-press) plus both targeting strategies: element by index/text/id, or a raw screen point (x, y). This is clearly distinguishable from the sibling 'tap' and 'swipe' by the press duration, 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?

Usage is only implied: you use long_press when you need a sustained press. It never says when to prefer it over tap or swipe, nor does it state prerequisites such as calling get_ui first to obtain an index, or the need for a screenshot for x/y targeting.

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