Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_scroll_find

Find an exact on-screen label, swiping a limited number of times if absent, and stop when it is ambiguous, covered, or not drawn. Returns the target or candidate labels for tapping.

Instructions

Find one exact label, swiping at most max_swipes times (default 1, max 5) when it is not on screen. Stops AT ONCE — no further swipe — when the label is ambiguous (several on-screen matches: candidates with index and frame), covered by another control, or not drawn. Found: target (index, kind, frame) plus a snapshot for phone_tap_element. Not found: on-screen labels containing the text as candidates. No screenshot is taken; absence after the budget is not proof — look at the screen before swiping further. Optional snapshot (from a read of the target app; never filled in for you): a known foreground app mismatch refuses before any swipe (app_changed). Setup may already have affected the device. Stops when ownership or privacy authorization changes and withholds observations. swipes_confirmed counts Native ACKs, not displacement; swipes_uncertain means no ACK and must not be replayed automatically. Requires phone_status drivable=true.

Input Schema

NameRequiredDescriptionDefault
kindNoNarrow to one element kind (e.g. `Button`) when a text shares the label.
labelYesExact label to find.
regionNoSwipe inside this normalized `[x, y, w, h]` area (default: whole screen).
instanceNoInstalled local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.
snapshotNoA snapshot from an earlier read of the target app: when given, a different foreground app refuses before any swipe. Not filled in for you.
directionNo`down` (default) or `up`: which way to look when the label is absent.
max_swipesNoSwipes allowed when the label is not on screen, 0–5 (default 1).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.27.34
    • addedInput schema / properties / max_swipes / minimum
      Added value: +0
  2. Changed1 schema field changedv0.27.3
    • addedInput schema / properties / instance
      Added value: +{
+  "description": "Installed local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.",
+  "type": "string"
+}
  3. First observedv0.21.0

TDQS

A3.8/5.0
Behavior3/5

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

The description discloses real behavior beyond the annotations: immediate stop on ambiguity, covered, or not-drawn elements; no screenshot taken; swipes_confirmed counts Native ACKs rather than displacement; swipes_uncertain must not be replayed; observations withheld if ownership/privacy authorization changes. These additions are substantive, but several statements are compressed to the point of being cryptic ('Setup may already have affected the device'), so the disclosure is rich yet unevenly legible.

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

Conciseness3/5

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

The output/mode split ('Found:' / 'Not found:') is well front-loaded, but the block is a long run of terse fragments, some of which are elliptical enough to require re-reading ('Stops when ownership or privacy authorization changes and withholds observations'). A few sentences, notably the setup-affect note, lack a clear antecedent.

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

Completeness4/5

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

With no output schema, the description properly carries the return contract: `target` (index, kind, frame), `candidates` with index and frame, `snapshot` for phone_tap_element, plus swipes_confirmed/swipes_uncertain semantics and the app_changed refusal. It is nearly complete for a 7-parameter, open-world tool; only the ownership/privacy stop condition remains under-explained.

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 100%, so the baseline is 3, and the description does add meaning for `snapshot` (never filled in for you; a foreground app mismatch refuses before any swipe with app_changed) and for `max_swipes` (default 1). Otherwise it largely restates what the schema already documents for label, kind, region, direction, and instance.

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

Purpose5/5

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

The opening clause gives a specific verb and resource ('Find one exact label') plus the operating mode (swipe at most max_swipes times when not on screen), so an agent knows exactly what the call does. It also distinguishes itself from related siblings by naming phone_tap_element as the consumer of the returned snapshot and phone_status as a prerequisite.

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

Usage Guidelines4/5

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

Usage context is strong: it warns 'absence after the budget is not proof — look at the screen before swiping further,' states the phone_status drivable=true prerequisite, and explains when a provided snapshot causes a pre-swipe refusal. It stops short of explicitly naming alternatives such as phone_scroll or phone_elements for non-label-driven scrolling.

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

Deploy Server

Other Tools