Skip to main content
Glama
Sign In
iphone-control

iphone-control

by Derrors
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

iphone_select_device

Idempotent

Switch control to another connected iPhone or iPad by UDID or device name so subsequent tools target that device; use auto to return to automatic selection.

Instructions

改为控制另一台设备,之后所有工具都作用在它上面,守护进程重启后还记得。device 是 UDID 或设备名(设备名包含这段文字且只有一台也行),auto 表示取消选定、改回自动选(正在控制的那台断开才换)。

何时用:接着多台设备、要操作的不是正在控制的那台。先用 iphone_list_devices 看有哪几台。

行为:切换后要在新设备上拉起 WDA(10~60 秒),期间读界面、按名字点击等用不了,先用 iphone_status 确认就绪;这台从没装过 WDA 时起不来,要请用户运行 iphone-control setup。自动解锁按设备分开存密码,新设备没设就不会自动解锁。设了 IPHONE_UDID 时不能切换。

返回:一行结果文字,例如「已切换到 Derrors 的 iPad(iPad11,1 iOS 26.6.1,00008020-…)」。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "device": "<device>"
    },
    "name": "iphone_select_device"
  }
}

Input Schema

NameRequiredDescriptionDefault
deviceYesUDID、设备名,或 auto(改回自动选)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A4.9/5.0
Behavior5/5

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

The annotations cover only the mutation and idempotency profile, while the description adds the operational behavior: a 10–60 second WDA boot on the new device during which UI tools fail; a failure mode when WDA was never installed, with the required user-side fix (iphone-control setup); and the fact that auto-unlock passwords are stored per device rather than migrated. That context on timing, failure, and credentials goes well beyond readOnly=false and idempotent=true.

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 uses labeled sections (when to use, behavior, return), with the core action and persistence guarantee placed first. Every sentence carries operational information; there is no filler or repetition of the tool name.

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?

Although this is a state-mutating tool with no output schema, the description documents the return value (a one-line confirmation string), the latency window, the failure and recovery path, and the interaction with credential storage. Nothing needed to call this tool correctly under multiple-device conditions 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?

The schema already documents the single parameter in brief, but the description clarifies that a name match is a substring match that must resolve to exactly one device, and that auto means deselect and revert to automatic selection, which only advances when the current device disconnects. This adds real matching semantics beyond 'UDID' and 'name', but it is only visible inside the usage section rather than attached to the parameter itself, so it does not reach the top score.

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: redirect control to another device, and it states that the selection persists across a daemon restart. This is clearly distinguished from the sibling iphone_list_devices (which only enumerates) and from iphone_status (which only verifies readiness).

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?

The description explicitly states when to use this tool: when multiple devices are connected and the target is not the one currently controlled. It also names a prerequisite (call iphone_list_devices first), a follow-up step (call iphone_status until WDA is ready), and a hard exclusion (switching is unavailable when IPHONE_UDID is set).

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