Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_jev_run

Destructive

Delegate a clear multi-step iPhone goal to an on-phone agent that chooses and executes each screen action, then returns done/blocked/max_steps with step history, useful when no saved flow fits.

Instructions

Hand ONE whole goal to a fast on-phone agent instead of driving it step by step: TypeSafe's Jev picks each next operation and target from the screen's element table (~1–2 s per step instead of a model turn), a small LLM types field values. Use it for a clear multi-step goal with no saved flow (check phone_flow_list first). It stops with status done / blocked / max_steps and the step history; it answers BLOCKED rather than send, pay, delete or share anything the goal did not explicitly ask for — still confirm such goals with the user first. Verify the end screen yourself. Needs TYPESAFE_API_KEY (or ~/.config/typesafe/key) and, for typing, TEXT_MODEL_API_KEY (or ~/.config/openrouter/key).

Input Schema

NameRequiredDescriptionDefault
appNoBundle id to launch first, e.g. `com.apple.Preferences`.
goalYesThe whole goal in plain language, with every value it needs ("In Settings, turn on Low Power Mode"). Jev never invents personal data.
instanceNoInstalled local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.
max_stepsNoStep budget (default 30).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.27.34
    • addedInput schema / properties / max_steps / 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.4/5.0
Behavior4/5

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

Goes well beyond the annotations by naming the terminal states (done / blocked / max_steps), returning step history, the ~1–2 s per-step cost profile, and the safety behavior of answering BLOCKED rather than sending, paying, deleting or sharing unrequested actions. That last point is the real value-add given destructiveHint=true and openWorldHint=true. Missing only finer detail such as what happens on a mid-run crash or how step history is shaped, which keeps it at 4 rather than 5.

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?

Front-loaded with the core distinction and the alternative check, then cost, then outputs, then safety, then credentials — a sensible priority order with no filler sentences. It is dense with parentheticals (key paths, timing) and runs long for a single prose block, costing it a point on readability.

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?

There is no output schema, and the description compensates by declaring the terminal statuses and that step history comes back. For an autonomous, non-idempotent, destructive-capable agent tool it also covers credentials (TYPESAFE_API_KEY, TEXT_MODEL_API_KEY with file fallbacks) and verification expectations, leaving no obvious gap for an agent to call it correctly.

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% and each parameter already carries a substantive description (app bundle id, instance with no fallback, max_steps default 30), so the schema does the heavy lifting. The description reinforces the goal contract ('with every value it needs', never invents personal data) and clarifies max_steps via the 'stops with ... max_steps' phrasing, but adds no format or syntax detail beyond the schema — baseline 3.

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 concrete verb and resource ('hand ONE whole goal to a fast on-phone agent') and immediately contrasts it with step-by-step driving, which is exactly the axis on which it differs from siblings like phone_run_steps and phone_tap_element. The mechanism (Jev picks the next operation from the screen's element table, a small LLM types values) makes the tool's role unmistakable.

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

Usage Guidelines5/5

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

Explicit when-to-use ('a clear multi-step goal with no saved flow'), an explicit prerequisite check ('check phone_flow_list first'), and explicit user-facing caveats ('confirm such goals with the user first', 'Verify the end screen yourself'). It routes the agent away from this tool when a saved flow exists and tells it what to do after the call.

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