Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_record

Record an iPhone screen to an MP4 on the daemon's Mac by starting, running the task, then stopping to get path, duration and size. Check status without starting a recording.

Instructions

Record the iPhone screen to an MP4 on the daemon's Mac: start, perform the requested task, then stop to get path, duration and size. status checks the recording without starting one. Unlike phone_screenshot (one image) or phone_screen (live panel), this persists video under the instance state directory's runs/recordings. Requires a usable device video stream and a writable output directory. Auto-stops after 10 minutes or 200 MB; ended explains why. Video can contain private screens: record only the authorized task, stop when done, and do not treat the returned Mac path as an upload.

Input Schema

NameRequiredDescriptionDefault
actionYes`start` recording the screen to an MP4, `stop` and save it, or `status`.
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.6/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: auto-stop at 10 minutes or 200 MB, 'ended' explains why a run stopped, the daemon-side storage location under runs/recordings, the required device stream and writable output, and an explicit privacy/security caution about screen contents and the returned Mac path. Nothing here merely restates readOnlyHint/openWorldHint.

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 lifecycle are front-loaded in the first clause, with differentiation and safety notes after. It is dense and packs several clauses into one paragraph, but almost every clause carries operational value; only the privacy admonition is marginally longer than needed.

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?

With no output schema, the description still covers what the agent gets back (path, duration, size, 'ended' reason), the failure prerequisites, the size/time caps, and where files land. That is everything needed to invoke and interpret the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with action values ('start', 'stop', 'status') already documented in the schema and the instance fallback behavior described there. The description adds no additional syntax or format detail for either parameter, so the baseline 3 applies.

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 ('Record the iPhone screen to an MP4') plus the lifecycle (start / task / stop), and explicitly contrasts itself with phone_screenshot (one image) and phone_screen (live panel). An agent can pick this over its siblings without reading 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?

Gives the operating sequence (start, perform task, stop to get path/duration/size), says when to use 'status' instead ('checks the recording without starting one'), and names the alternatives plus the condition that distinguishes them. Prerequisites (usable video stream, writable output dir) are also stated.

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