Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_key

Destructive

Press navigation or editing keys in the foreground iOS app to act on its current focus; use it for return, delete, tab, arrows, or escape when you need keyboard-level control.

Instructions

Press a navigation or editing key in the foreground app, acting on its current focus. Use phone_type for literal text and phone_tap_element to focus a field first. Check phone_status.drivable and the focused control: delete/backspace can erase content, and return/enter may submit or send it. The schema lists accepted names; unsupported names fail before input is sent. observe defaults on and returns the settled screen change. On an unknown outcome, inspect the screen before another key; repeating a key can change or submit content twice.

Input Schema

NameRequiredDescriptionDefault
nameYesSupported names: `return`/`enter`, `escape`, `space`, `tab`, `delete`/`backspace`, `up`, `down`, `left`, `right`.
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.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"
+}
  2. First observedv0.21.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, yet the description still adds real context: unsupported names fail before any input is sent, observe defaults on and returns the settled screen, and repeating a key can submit or erase content twice. It stops just short of describing per-key effects in detail.

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

Conciseness5/5

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

Four sentences, no filler. The core action is front-loaded, followed by alternatives, then hazards, then the failure/observe behavior — each sentence carries distinct operational value.

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, non-idempotent input tool with no output schema, the description covers preconditions, side effects, return behavior ('the settled screen change'), and recovery on ambiguous results. Nothing an agent needs to invoke it safely 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 the baseline is 3; the description earns an extra point by explaining what 'observe' returns and by adding validation behavior for 'name' (unsupported names fail before input is sent) beyond the schema's accepted-name list.

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 ('press a navigation or editing key') plus scope ('in the foreground app, acting on its current focus'). It actively distinguishes itself from siblings by naming phone_type and phone_tap_element and stating what each is for.

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_type for literal text, phone_tap_element to focus a field first, and check phone_status.drivable prior to acting. It also gives a when-not rule for retries ('on an unknown outcome, inspect the screen before another key').

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