Lists apps installed on a connected iPhone or iPad, with an option to include Apple system apps.
List apps installed on the device.
| Name | Required | Description | Default |
|---|---|---|---|
| device | No | Device UDID or name substring. Defaults to the select_device choice, then IOS_DEVICE_MCP_DEVICE, else the single USB-connected device. | |
| includeSystem | No | Include Apple system apps |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it only adds the word 'installed'. It does not say whether the result contains bundle identifiers or display names, whether system apps are excluded by default, or what happens when no device is connected or multiple devices match.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero waste. It is efficient, but the terseness edges toward under-specification rather than optimal density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two fully documented optional parameters, so the schema covers the mechanics. However, with no output schema the description should at least indicate what a listed app looks like (identifier vs. display name), since downstream calls like launch_app or uninstall_app depend on that form.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the two parameters are already documented, and the description adds nothing on top. Notably it omits the behavioral default for includeSystem (system apps excluded unless set), which is meaningful for callers even though the schema documents the field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List apps installed on the device'), which is immediately actionable. It does not differentiate itself from adjacent siblings such as list_devices or list_app_files, so an agent must infer the boundary from names alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus list_devices or list_app_files, and no mention of prerequisites (e.g., that a device must be selected or connected). The agent gets a purpose but no routing rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.