agent-device

Official

Overview Schema Source Related Servers Discussions Admin

fold

Change a hinged iPhone simulator or Android emulator between closed, half-open, and open poses; confirm hinge/device state, then re-snapshot because panel changes invalidate refs.

Instructions

Fold or unfold a foldable iPhone simulator (iPhone Duo) or a foldable Android emulator into the closed, half-open, or open pose. iOS sends a simulator HID hinge event, then reads the hinge angle back inside the simulator to confirm it, and can follow timestamped angle keyframes; Android sets the emulator console posture, then confirms the device state the guest commits and reports the angle read from the hinge sensor, which can differ from the AVD profile's per-posture angles, and dismisses the lock screen a fold to the cover display can raise. On iOS a pose change moves the app to a different panel with a different point size; on Android a fold to or from closed moves the app between the cover and inner displays, and any pose change can reshape the app window, whose size the next snapshot reports. Either way every ref and coordinate from before it is stale: re-snapshot after this command. Taps, long presses, and scrolling target the app window on its current panel in closed, half-open, and open poses. Simulator and emulator only; iOS requires the iOS simulator SDK; Device Hub and host Accessibility permission are not required. An iOS simulator in a scoped simulator set folds the same way as one in the default set. Times out after 255s.

Input Schema

Name	Required	Description
`pose`	No	Instant preset; mutually exclusive with keyframes.
`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.
`keyframes`	No	Piecewise-linear hinge motion. Start at 0ms; strictly increasing timestamps, up to 60000ms. Repeated angles create holds. Mutually exclusive with pose.
`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

Name	Required	Description
`pose`	Yes
`action`	Yes
`screen`	No
`message`	Yes
`hingeAngleDegrees`	Yes	Hinge angle read back after the pose settled: from CoreMotion inside the simulator on iOS, from the emulator hinge sensor on Android.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.21.32Oct 26, 2026

changedOutput schema / properties / hingeAngleDegrees / description

Previous value: -"Hinge angle read back after the pose settled: from CoreDevice on iOS, from the emulator hinge sensor on Android."New value: +"Hinge angle read back after the pose settled: from CoreMotion inside the simulator on iOS, from the emulator hinge sensor on Android."

Changed1 schema field changedv0.21.27Oct 12, 2026

changedOutput schema / properties / hingeAngleDegrees / description

Previous value: -"Hinge angle CoreDevice read back after the pose settled."New value: +"Hinge angle read back after the pose settled: from CoreDevice on iOS, from the emulator hinge sensor on Android."

Addedv0.21.12Sep 23, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains iOS HID hinge events and angle confirmation, Android emulator posture confirmation, lock-screen dismissal, panel/display changes, window reshaping, stale refs requiring re-snapshot, and a 255s timeout. These are exactly the side effects and platform-specific behaviors an agent needs before invoking a mutating device-control tool.

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?

The purpose is front-loaded and the later sentences carry useful behavioral context, but the description is dense and includes several long, comma-heavy clauses. It is efficient for its complexity, though not maximally concise.

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?

Given a complex 18-parameter tool with a rich schema and an output schema, the description covers platform behavior, prerequisites, post-condition staleness, interaction implications, and timeout behavior. Nothing critical for correct invocation appears 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 already 100%, so the baseline is 3. The description adds some contextual meaning about pose and timestamped keyframes, but it does not add material semantics beyond what the schema already documents for the 18 parameters.

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: it folds or unfolds a foldable iPhone simulator or Android emulator into closed, half-open, or open poses. It also distinguishes this tool from generic orientation/gesture siblings by scoping it to foldable simulator/emulator hinge poses.

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?

It clearly scopes usage to simulator and emulator only, notes that iOS requires the iOS simulator SDK, and says Device Hub and host Accessibility permissions are not required. It does not explicitly name alternatives such as orientation or gesture tools for non-foldable devices, so it stops short of full when/when-not/alternative guidance.

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

Deploy Server