Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_shortcut

Destructive

Trigger iPhone system shortcuts—Home, Spotlight, volume buttons, or save a screenshot to Photos—to navigate or control device state without manual taps.

Instructions

Use Home (home), Spotlight (spotlight), physical volume buttons (volume_up, volume_down), or request a system screenshot in Photos (save_screenshot). Volume acknowledgement confirms only a button request, not the volume level; Simulator and older Runners without ipu:volumeButtons refuse before dispatch. save_screenshot is a mutation, unlike phone_screenshot which only returns image bytes. Its receipt means requested, not saved_verified, and requires ipu:systemCaptureRequest. If iOS opens a screenshot preview, inspect the system UI and choose Done/Save to Photos for that existing image; never take another screenshot to complete its save. Check Photos or its picker before claiming it saved. Never replay an uncertain capture or volume request. Navigation leaves the current app or changes its visible state. Use phone_key for field keys, or phone_run_steps with launch_app for a specific app. Requires phone_status.drivable=true. Names are trimmed and case-insensitive. switcher and other names fail before input is sent; the runner cannot synthesize the App Switcher gesture. observe defaults on and returns the settled screen change. Verify it before another action; repeating system navigation may lose the current context.

Input Schema

NameRequiredDescriptionDefault
nameYesHome, Spotlight, Photos capture (`save_screenshot`), or physical-only `volume_up` / `volume_down`. App Switcher is unsupported by the device runner.
observeNoDefault true: return what the screen settled to (as on phone_tap). `false` for the fastest bare action.
instanceNoInstalled local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.27.7
    • changedInput schema / properties / name / description
      Previous value: -"Supported names: `home` (Home Screen) and `spotlight` (search).\nApp Switcher is unsupported by the device runner."New value: +"Home, Spotlight, Photos capture (`save_screenshot`), or physical-only `volume_up` / `volume_down`.\nApp Switcher is unsupported by the device runner."
  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
Behavior5/5

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

Annotations declare destructive/openWorld/non-idempotent, and the description adds the details that matter: receipts mean 'requested, not saved_verified', volume acknowledgement is not a level confirmation, navigation changes app state, and uncertain captures must never be replayed. This is exactly the extra context annotations cannot express, and it is consistent with destructiveHint=true.

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?

It is a dense, run-on block rather than front-loaded clauses, and several points are stated twice – the 'requested vs saved_verified' receipt and 'check Photos before claiming saved' cover the same ground, as do 'navigation leaves the current app' and 'repeating system navigation may lose context'. Nearly every sentence earns its place, but the duplication costs it.

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?

For a destructive, gated, open-world system-action tool with no output schema, the description covers valid inputs, refusal conditions, permission requirements, verification steps, and non-retry policy. Nothing an agent needs before invoking it is missing.

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 baseline is 3, but the description adds real meaning about the name values: they are trimmed and case-insensitive, 'switcher' and other names fail before input is sent, and each named shortcut has documented side effects. The observe default is explained consistently in both places, which is mild redundancy.

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?

The description enumerates the concrete shortcuts (Home, Spotlight, volume buttons, Photos screenshot) so the agent knows what the tool does despite the vague name 'shortcut'. It also distinguishes itself from phone_screenshot, phone_key, and phone_run_steps. The only weakness is that no single sentence states the purpose up front – the enumeration does the work.

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 routing: 'Use phone_key for field keys, or phone_run_steps with launch_app for a specific app', plus 'save_screenshot is a mutation, unlike phone_screenshot which only returns image bytes'. It also states preconditions (phone_status.drivable=true, ipu:volumeButtons, ipu:systemCaptureRequest) and what fails before dispatch.

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