Skip to main content
Glama
ios-control-mcp

ios-control-mcp

by als0m3

iphone_list_devices

Lists attached iPhones with UDID, transports, iOS version, model, Developer Mode status, and control readiness, letting you verify preconditions before selecting or driving a device.

Instructions

List every attached device with its UDID, transports, iOS version, model and Developer Mode, and whether it meets the preconditions to be driven. Does not open a tunnel or select a device.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "iphone_list_devices"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full disclosure burden. It does disclose that the call is non-tunneling and non-selecting ('whether it meets the preconditions to be driven'), which implies a side-effect-free enumeration, but it does not explicitly state read-only/safety semantics, whether device connection or auth is required, or what happens when no devices are attached.

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?

A single front-loaded sentence listing outputs followed by a short scope disclaimer, with no filler. The field enumeration is a bit dense but each item earns its place by telling the agent what it can rely on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero params, no annotations, and no output schema, the description must carry the whole burden. It covers outputs and scope adequately but omits return shape (list vs. single object), pagination, and failure behavior for a device-discovery tool.

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 tool takes zero parameters, so there is no parameter semantics to add; baseline 4 applies. The description briefly clarifies that filtering/selection is intentionally absent.

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 (list attached devices) and enumerates the returned fields (UDID, transports, iOS version, model, Developer Mode, precondition status). It also distinguishes itself from siblings by declaring it does not open a tunnel or select a device, so an agent can separate it from iphone_status or the interaction tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The negative scoping clauses ('Does not open a tunnel or select a device') imply it is a discovery step before tunneling or interaction, but no positive when-to-use guidance or explicit alternative (e.g. iphone_status vs iphone_list_devices) is named. Usage is inferable rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.