Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_flow_draft

Converts recorded phone actions into a draft flow document and returns a todo list. Optionally saves and validates the new flow file for replay.

Instructions

Turn what you just did on the phone into a flow. The daemon records every action it applied in the current app (single actions and phone_run_steps batches, not flow runs); this returns that trail as a flow v1 document (snapshot taps become label/identifier locators, typed text becomes named inputs and is never included) plus a todo list of what to fix. Call it when a response carried flow_suggestion, or after any multi-step task with no matching flow — but ASK THE USER before saving. With save_as, the draft is written to that new file and validated; fix the todo items, prove it with phone_flow_run(id=), then publish only with the user's OK.

Input Schema

NameRequiredDescriptionDefault
save_asNoOptional path to write the draft flow to (a new `.json` file; existing files are never overwritten). It is validated after writing.
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.8/5.0
Behavior5/5

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

Annotations already mark this as a non-read-only, non-destructive, non-idempotent write, and the description adds substantial context beyond them: what is recorded (single actions and phone_run_steps batches, not flow runs), what is deliberately excluded (typed text never included), and the file-write safety property (save_as never overwrites existing files, validated after write). This is rich disclosure an agent could not infer from structured fields.

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?

Dense but front-loaded, with the core action stated first and the workflow and caveats following. The parenthetical aside is slightly run-on, but every sentence carries actionable information; minor tightening would make it a 5.

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?

No output schema exists, and the description fills that gap by explaining the return value (a flow v1 document with locator/input mapping plus a `todo` list). Combined with prerequisites and the follow-on workflow, an agent has everything needed to call and use it correctly.

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 schema already documents both params, making baseline 3 appropriate. The description goes further by explaining the save_as lifecycle (write to new file, validate, then fix/run/publish), adding meaning beyond the schema, though it does not discuss the `instance` parameter.

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 ('turn what you just did on the phone into a flow') and clarifies the mechanism (daemon action trail, not flow runs). It clearly distinguishes this drafting tool from siblings like phone_flow_run, phone_flow_list, and phone_flow_publish.

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?

Gives explicit triggers ('when a response carried flow_suggestion, or after any multi-step task with no matching flow'), an exclusion, and a mandatory prerequisite ('ASK THE USER before saving'). It also names the follow-on workflow (fix todo, phone_flow_run, publish with user OK), routing the agent precisely.

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