Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_type

Destructive

Insert Unicode text into the currently focused iPhone field, optionally clearing it first. Focus the target field beforehand and verify the resulting field, especially after partial or unknown outcomes.

Instructions

Insert literal Unicode text into the currently focused iPhone field. Use phone_tap_element to focus the intended field first; use phone_key for a navigation or editing key. Requires phone_status.drivable=true. Text can replace a selection or reach the wrong field if focus changed. Long text is chunked. Optional budget_ms (6000..15000) can stop at a safe boundary; continue only with the returned continue_token, without text/clear/budget_ms. Tokens are single-use and scoped to the original field, owner, privacy, lifecycle and session. Unknown outcomes never issue a token. On partial failure inspect characters_confirmed and remaining_text; never resend the whole value blindly. observe defaults on and returns the settled screen change. Verify the resulting field before submitting; an unknown outcome is not evidence that nothing was typed.

Input Schema

NameRequiredDescriptionDefault
textNoUnicode text to start typing, up to 20000 scalars. Omit when continuing.
clearNoClear the bound field first. Never combine with continue_token.
observeNoDefault true: return the settled screen change after a completed action.
instanceNoInstalled local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.
budget_msNoOptional typing budget, 6000..15000 ms, requiring a named owner and inputContinuation.
continue_tokenNoSingle-use token from a safe chunk boundary. Pass without text, clear or budget_ms.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.27.34
    • addedInput schema / properties / budget_ms
      Added value: +{
+  "description": "Optional typing budget, 6000..15000 ms, requiring a named owner and inputContinuation.",
+  "maximum": 15000,
+  "minimum": 6000,
+  "type": [
+    "integer",
+    "null"
+  ]
+}
    • addedInput schema / properties / clear
      Added value: +{
+  "description": "Clear the bound field first. Never combine with continue_token.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
    • addedInput schema / properties / continue_token
      Added value: +{
+  "description": "Single-use token from a safe chunk boundary. Pass without text, clear or budget_ms.",
+  "maxLength": 64,
+  "minLength": 64,
+  "pattern": "^[0-9a-f]{64}$",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • removedInput schema / properties / observe / default
      Removed value: -null
    • changedInput schema / properties / observe / description
      Previous value: -"Default true: return what the screen settled to (as on phone_tap).\n`false` for the fastest bare action."New value: +"Default true: return the settled screen change after a completed action."
    • changedInput schema / properties / text / description
      Previous value: -"Unicode text to send through the device-side input service. Focus the\nintended field and verify it before typing. Up to 20000 characters;\ntext over 200 is typed in chunks (about a minute per 3000 characters),\nand a failure part-way reports `characters_confirmed` and\n`remaining_text` with retry_safe=false — then type only the rest."New value: +"Unicode text to start typing, up to 20000 scalars. Omit when continuing."
    • changedInput schema / properties / text / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • removedInput schema / required
      Removed value: -[
-  "text"
-]
  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. Changed1 schema field changedv0.22.4-glama.1
    • addedInput schema / properties / text / maxLength
      Added value: +20000
  4. First observedv0.21.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the mutation/destructive profile; the description adds substantial depth beyond them: focus can shift and text can reach the wrong field, long text is chunked at safe boundaries, tokens are single-use and scoped to field/owner/privacy/lifecycle/session, and unknown outcomes never issue a token. It also discloses partial-failure recovery via characters_confirmed and remaining_text and warns that an unknown outcome is not evidence nothing was typed.

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?

Purpose and focus prerequisite are front-loaded, then budget/token mechanics, then failure handling and verification, in a logical order with no filler. It is dense and telegraphic to the point that a couple of clauses (token scoping dimensions) read as enumerated keywords, but every sentence conveys operational information.

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, open-world typing tool with no output schema, the description covers what an agent needs before and after invocation: precondition gating, chunking and continuation, partial-failure inspection fields, and a verification instruction before submitting. Nothing material to calling it correctly 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, but the description adds relational meaning the per-parameter descriptions do not carry on their own: the budget_ms/continue_token protocol, the incompatibility of tokens with text/clear/budget_ms, and the meaning of an absent token on unknown outcome. It does not spell out the `instance` or `clear` selection semantics, keeping it from a 5.

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 ('Insert literal Unicode text into the currently focused iPhone field') and immediately distinguishes itself from phone_tap_element (focusing) and phone_key (navigation/editing keys). An agent can tell exactly what this tool does versus its siblings without opening any schema.

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?

Explicitly names the precondition sequence (focus with phone_tap_element first), the alternative for keys (phone_key), and the gating requirement (phone_status.drivable=true). It also states the continuation path for budget_ms and the prohibition on reusing text/clear/budget_ms with a token, which is genuine when/when-not guidance.

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