Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_run_start

Opens a task boundary for session daemon metrics, pairing with phone_run_end so later calls count toward this run. Use a fresh run_id per task and report errors instead of assuming metrics were recorded.

Instructions

Open a task boundary for this session's daemon metrics; pair with phone_run_end, not phone_record (video). Later session calls count toward this run; this does not drive or reserve the phone. Optional: without it, idle gaps infer runs. Use a fresh run_id for each task; starting the same still-open id resumes that run rather than resetting its counts. complete_trace is valid only before its first counted call and commits you to supply every model turn id at run_end. Returns a start acknowledgement; report errors rather than claiming metrics were recorded.

Input Schema

NameRequiredDescriptionDefault
run_idYesA short id for this task: 1–64 of A-Z a-z 0-9 . _ : @ -
instanceNoInstalled local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.
complete_traceNoSet only if you will pass the id of EVERY model turn of this task to phone_run_end (including turns that made no tool call); only then are model round trips reported.

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.9/5.0
Behavior5/5

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

The annotations already declare this is not read-only, not idempotent, not destructive, and not open-world; the description adds substantial context beyond that. It clarifies that the tool does not drive or reserve the phone, how later calls count toward the run, what happens when reusing an open run_id, and what complete_trace commits the caller to.

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?

The description is front-loaded with its core purpose, then packs only relevant operational details into a compact paragraph. Each clause adds distinct value: alternative routing, optionality, run_id reuse, complete_trace timing, and error-reporting behavior.

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?

Given there is no output schema, the description correctly states what is returned: a start acknowledgement and the need to report errors rather than assume metrics were recorded. It also covers the tool's operational role, optionality, and key constraints, making the definition complete for correct invocation.

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 parameter documentation already carries much of the burden. The description still adds meaning beyond the schema by explaining run_id freshness versus resuming an existing open run, and by adding the timing constraint for complete_trace that the schema alone does not state.

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?

The description opens with a specific verb and resource: 'Open a task boundary for this session's daemon metrics.' It immediately distinguishes this from sibling tools by naming phone_run_end and explicitly excluding phone_record (video), so an agent can identify the correct tool without opening the 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?

It gives explicit pairing guidance ('pair with phone_run_end, not phone_record'), states that it is optional, and explains the fallback behavior ('without it, idle gaps infer runs'). It also covers run_id reuse semantics and the complete_trace timing constraint, leaving very little to inference.

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