agent-device

Official

Overview Schema Source Related Servers Discussions Admin

action-button

Presses an iPhone/iPad Action Button once to trigger its assigned shortcut without launching the session app or changing app state. Use it to verify Shortcut delivery on physical devices.

Instructions

Press the iPhone or iPad Action Button once. The press is dispatched without activating the session app and nothing is re-observed afterwards, so the app keeps the state the press found. What the system does with the press is not observed by this command: Simulators run no Shortcuts or App Intents, so delivery to an assigned Shortcut is verifiable only on a physical iPhone. Times out after 90s.

Input Schema

TableJSON Schema

Name	Required	Description
`udid`	No	Apple device or simulator UDID; the selector that pins one device when several share a name.
`debug`	No	Enable debug diagnostics.
`runId`	No	Lease run identifier.
`device`	No	Device name selector (a UDID belongs in udid, a serial in serial).
`serial`	No	Android, HarmonyOS, or Vega VVD serial selector.
`target`	No	Alias for deviceTarget on commands without a UI target field. Interaction commands reserve target for the UI element.
`tenant`	No	Remote tenant identifier.
`leaseId`	No	Existing lease identifier.
`session`	No	Agent-device session name.
`noRecord`	No	Do not record this action.
`platform`	No	Platform selector used to resolve a device.
`includeCost`	No	Include per-command agent-cost (cost.wallClockMs, …) in structuredContent. Defaults to off; the default response shape is unchanged.
`deviceTarget`	No	Device target form. Maps to the CLI --target flag.
`responseLevel`	No	Response verbosity: token-cheap digest / default (today) / full. Defaults to default; the default response shape is unchanged.
`mcpOutputFormat`	No	MCP text content format. Defaults to optimized agent-friendly text; use json for JSON text. Structured content is always returned separately.
`androidDeviceAllowlist`	No	Android serial allowlist used for device resolution.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`action`	Yes
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.21.12Sep 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the press does not activate the session app, that nothing is re-observed so state is preserved, that the system's response is not observed, and that the command times out after 90 seconds. This is unusually thorough.

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 is three focused sentences with no filler. The core action is front-loaded, followed by the most important behavioral caveat and the timeout. Every sentence adds information an agent needs.

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?

The tool has no annotations but has a rich input schema and an output schema. The description covers the essential non-obvious runtime behavior: side-effect scope, observation behavior, simulator limitations, verification constraints, and timeout. Nothing critical is missing for correct invocation.

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%, so the baseline applies: the schema already explains every parameter. The description adds no parameter-specific guidance, which is acceptable because the structured schema does the heavy lifting.

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: 'Press the iPhone or iPad Action Button once.' It also differentiates the action from generic siblings by noting the press is dispatched without activating the session app and that nothing is re-observed afterwards, making the tool's scope unmistakable.

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

Usage Guidelines4/5

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

The description gives clear context for when the tool is meaningful, notably that delivery to a Shortcut is verifiable only on a physical iPhone and that simulators run no Shortcuts or App Intents. It does not explicitly name alternative sibling tools or state 'use this instead of X', but the practical when/when-not context is present.

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

Deploy Server