Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_collect_list

Reads a scrolling list across multiple pages in one call, avoiding repeated scroll-and-read turns. Stops on a repeated page, an end label, or the page limit and returns deduplicated rows.

Instructions

Read a scrolling list across pages in ONE call instead of scroll + read turns: reads the rows of one kind (default Cell) on screen, swipes one page, reads again, and stops when the exposed page repeats (duplicate_page), end_label is on screen, or max_pages (default 6, max 10) is reached. Rows are deduplicated on (kind, identifier, label, value): different exposed identifiers preserve identical-looking rows. Absent or reused identifiers with identical content may still collapse, so reconcile counts the user cares about. complete is true ONLY when end_label was seen (complete_scope=end_label_visibility); business_complete is always false. duplicate_page is not proof the list ended. Changed pages continue even with no new deduplicated rows. Only what the accessibility tree exposes is collected. It swipes the live list, so the screen is left where the last page was; snapshot is that last page. 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). Results name the app. Owner/privacy changes stop further reads and scrolling. swipes_confirmed counts Native ACKs, swipes_uncertain may have reached the device; never replay uncertain scrolling. Requires phone_status drivable=true.

Input Schema

NameRequiredDescriptionDefault
regionNoOnly rows whose centre lies in this normalized `[x, y, w, h]` area, and swipes inside it (default: the whole screen).
instanceNoInstalled local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.
row_kindNoElement kind of one list row (default `Cell`; e.g. `StaticText`, `Button`, `Link`). A row without a label is named by its texts.
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) reveals rows below, `up` rows above.
end_labelNoExact label that marks the end of the list ("没有更多了", "No more results"). Only this makes the result `complete:true`.
max_pagesNoPages to read, 1–10 (default 6). One swipe between pages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.27.34
    • addedInput schema / properties / max_pages / 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

A4.6/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false; the description adds far more: stop conditions (duplicate_page, end_label, max_pages), why duplicate_page is not proof of the end, that only accessibility-tree-exposed content is collected, that the screen is left on the last page, that a snapshot mismatch refuses before swiping, that owner/privacy changes halt reads, and that uncertain swipes must never be replayed. This is consistent with readOnlyHint=false since it swipes the live device.

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?

Core purpose is front-loaded in the first clause and nearly every sentence carries operational signal. It is dense to the point of a run-on and repeats the duplicate_page idea ('stops when the exposed page repeats' then 'duplicate_page is not proof the list ended'), which costs some tightness.

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

Completeness5/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 carries the burden of explaining returns and does so: rows and deduplication, `complete`, `business_complete`, `duplicate_page`, `snapshot`, `swipes_confirmed` vs `swipes_uncertain`, and that results name the app. For a 7-parameter, state-changing tool, an agent has enough to call it correctly and interpret the response.

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

Parameters4/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; the description earns above that by adding semantics the schema lacks — the dedup key (kind, identifier, label, value), that end_label alone drives complete:true, that max_pages caps at 10, and that snapshot is never auto-filled. It does repeat some schema-stated defaults (default Cell, default 6).

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?

States a specific verb and resource — read a scrolling list across pages in one call, reading rows of one kind, swiping, re-reading — and explicitly contrasts it with the 'scroll + read turns' pattern a sibling like phone_scroll would require. An agent can tell what it does without opening the schema.

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?

Says when to prefer it (batch list collection instead of alternating scroll and read turns) and gives a prerequisite, 'Requires phone_status drivable=true'. It does not explicitly name the alternatives (phone_scroll, phone_scroll_find) or state when not to use it, so routing between list tools is still partly inferred.

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