agent-device

Official

Overview Schema Source Related Servers Discussions Admin

telephony

Simulate an incoming phone call or SMS on an Android emulator through its console over adb: call rings from the number, accept answers, cancel ends the call, and sms delivers a text message.

Instructions

Simulate an incoming phone call or SMS on an Android emulator through its console over adb: call rings from the number, accept answers, cancel ends the call, and sms delivers a text message. The call screen or notification can cover the app, so re-snapshot afterwards. Times out after 90s.

Input Schema

Name	Required	Description
`text`	No	Message text for sms; required for sms and refused for the call actions. The emulator drops characters outside the Basic Multilingual Plane, such as emoji.
`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.
`action`	Yes	call starts an incoming call, accept answers it, cancel ends it, sms delivers a text message.
`device`	No	Device name selector (a UDID belongs in udid, a serial in serial).
`number`	Yes	Caller or sender phone number: digits with an optional leading +.
`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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.21.29Oct 23, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the execution path (emulator console over adb), a hard 90s timeout, and a real side effect (call UI occludes the app, so re-snapshot). It says nothing about prerequisites such as a booted, connected emulator, whether an accept without a ringing call errors, or whether any state persists.

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?

Two sentences, purpose front-loaded, no filler. The action glosses are compact and the caveat and timeout are appended in the right place. The first sentence is dense but every clause conveys behavior.

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?

For a 19-parameter tool with an output schema, the description covers purpose, timing and the post-action caveat adequately. It is incomplete on device selection, though: the schema exposes udid, platform (apple/ios/macos) and serial (Android/HarmonyOS/Vega), yet the description scopes the tool to an 'Android emulator', which can steer an agent away from valid iOS/simulator use.

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 schema already documents all 19 parameters including the action enum and the text-required-for-sms constraint. The description's action gloss largely restates the enum description, adding no format or selection detail beyond the schema; baseline 3 applies.

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 pair (simulate a call/SMS) plus scope (Android emulator via adb console) and enumerates the four actions with their effects: call rings, accept answers, cancel ends, sms delivers. No sibling tool touches telephony, so the agent can route here unambiguously.

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?

Explains the sequencing implied by the actions (a call rings, accept answers it, cancel ends it) and gives a concrete operational instruction: re-snapshot afterwards because the call screen or notification can cover the app. It does not name when to avoid the tool or what to do if no device/emulator is attached, so it stops short of full when/when-not guidance.

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

Deploy Server