Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_release_owner

Idempotent

Releases this session's iPhone lease so another session can take control immediately. Use it when a task ends to give up ownership; returns ok when the phone is already unowned.

Instructions

Release this session's phone lease when its task ends, so another session can drive immediately. Unlike phone_hold(secs=0), this gives up ownership rather than merely clearing a pause. It sends no phone input and returns ok with owner=null; releasing an already-unowned phone succeeds. A different session's active lease returns phone_owned and is never taken over. Authentication/transport failures are errors; check phone_status.owner before assuming the lease was released.

Input Schema

NameRequiredDescriptionDefault
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
Behavior5/5

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

Goes well beyond the annotations by disclosing the success shape (ok with owner=null), that releasing an already-unowned phone succeeds, the exact failure mode for another session's lease (phone_owned, never taken over), and that auth/transport failures surface as errors. It even recommends a verification step via phone_status.owner. This is fully consistent with readOnlyHint=false and idempotentHint=true and adds real context on top.

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 tight sentences, front-loaded with the primary action and its effect, then the disambiguation, then outcomes and error semantics. No filler or redundancy; every sentence carries distinct 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?

With no output schema, the description carries return-value duty and does so (ok/owner=null vs phone_owned), plus error behavior and a verification hint. For a single optional-parameter mutation tool, nothing an agent needs to call it correctly is missing.

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 description coverage is 100% and the single optional 'instance' parameter is fully documented in the schema, so the description need not repeat it. The description adds no parameter meaning of its own, which is the baseline 3 case.

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 (release) plus resource (this session's phone lease) and the triggering condition (when its task ends). It explicitly positions itself against the sibling phone_hold(secs=0), so an agent can distinguish the two without reading either 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?

Names the alternative (phone_hold with secs=0) and explains exactly how they differ in effect: giving up ownership versus clearing a pause. It also implies when release is appropriate (task ends, wanting another session to drive immediately).

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