Skip to main content
Glama
Sign In
ios-device-mcp

ios-device-mcp

by ChrisThoma
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

siri

Send text to the voice assistant as spoken input, tap buttons it displays, and return the response text for automation and app testing.

Instructions

Send text to Siri as if it had been spoken, or tap something Siri is showing, then return the text Siri shows. Use tap for Siri's buttons, because a coordinate tap goes to the app behind Siri and dismisses it. Anything Siri can do runs for real, including App Intents. An app's first-run "Turn on shortcuts with Siri?" prompt fails with "Something went wrong" after text sent this way. Use Type to Siri for that once: double_tap the bottom edge of the screen, tap the "Ask Siri" field so the keyboard shows, type_text the phrase, then tap the send arrow at the field's right end by coordinates from a screenshot (return adds a line, and while the keyboard is up Siri reports its buttons below the screen, so tap: "Submit" hits a key). When the prompt shows, use tap: "Turn On". Later phrases work with text.

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": "siri"
  }
}

Input Schema

NameRequiredDescriptionDefault
tapNoLabel of a button or row Siri is showing, instead of text
textNoWhat to say to Siri
waitNoSeconds to wait before reading Siri's UI (default 6)
deviceNoDevice UDID or name substring. Defaults to the select_device choice, then IOS_DEVICE_MCP_DEVICE, else the single USB-connected device.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it warns that anything Siri can do runs for real, including App Intents, which signals real side effects, and it documents a specific failure mode ('Something went wrong') plus a workaround. It does not cover permission prerequisites, timeout behavior when wait is exceeded, or what happens if Siri is disabled, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the key tap-vs-text caveat are front-loaded, which is good, but the middle passage is a dense run-on ('return adds a line, and while the keyboard is up Siri reports its buttons below the screen, so tap: "Submit" hits a key') that takes effort to parse. The Type to Siri workaround is useful but nearly half the definition and could be tightened.

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

Completeness4/5

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

No output schema exists, and the description does explain the return value (the text Siri shows, with the caveat that return adds a line). For a no-annotation, 4-parameter tool with real side effects, it supplies the destructive/mutation context and the main failure mode; missing pieces are error/timeout semantics and any permission requirements.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: tap is a mutual alternative to text (button label 'instead of text'), and it explains the off-screen coordinate problem and why tap: 'Submit' hits a key while the keyboard is up. The wait parameter's purpose (reading Siri's UI after the delay) is implied rather than restated.

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 ('Send text to Siri as if it had been spoken, or tap something Siri is showing, then return the text Siri shows'), covering both the text and tap modes and the return value. It also distinguishes itself from the sibling tap tool by explaining that a coordinate tap lands on the app behind Siri. An agent can pick it out of the sibling list without opening the schema.

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

Usage Guidelines5/5

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

Explicitly routes the agent: use the tap parameter for Siri's buttons instead of the coordinate tap tool, and use the Type to Siri path via double_tap/type_text/screenshot when an app's first-run shortcuts prompt appears. It names the alternatives (tap, double_tap, type_text, screenshot) and the exact condition that selects each, and says later phrases work normally with text.

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

Deploy Server

Other Tools