Swipium

Overview Schema Source Related Servers Discussions Admin

iOS simulator control

qa_ios

Destructive

Control an iOS Simulator to boot, install, launch, or terminate apps, open deep links, and collect logs. Use consent-gated reset or erase actions for clean QA runs.

Instructions

Control an iOS Simulator (macOS): list, boot (binds it to the session), install (.app), launch, terminate, openurl, logs, privacy_reset, erase (wipes it). install, privacy_reset and erase are consent-gated. A slow cold boot returns status:"booting" (poll qa_wait for:"simulator_booted"). Structured iOS automation: qa_wda.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sessionId": "<sessionId>",
      "action": "<action>"
    },
    "name": "qa_ios"
  }
}

Input Schema

Name	Required	Description
`app`	No	install: .app path (absolute or project-relative).
`url`	No	openurl: deep link.
`last`	No	logs: time range, e.g. 30m (default 5m).
`action`	Yes
`device`	No	boot/erase: simulator UDID or exact name (other actions: the bound one only).
`approve`	No
`service`	No	privacy_reset: service, e.g. location, photos, all.
`bundleId`	No	launch/terminate/privacy_reset: bundle id.
`consentId`	No
`sessionId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: boot is session-binding (stateful), erase wipes the device, three actions are consent-gated, and a slow cold boot returns status 'booting' rather than completing — an async trait the agent must handle by polling. The destructive and non-idempotent hints are corroborated and enriched rather than repeated.

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?

Front-loaded with the resource, then a compact action inventory, then constraints and the sibling route in descending order of importance. Terse parentheticals ('binds it to the session', 'wipes it') carry real information with no filler sentences.

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?

For a 10-parameter, no-output-schema tool it covers the high-risk paths: session binding, destructive erase, consent gating, and async boot polling. Minor gaps remain around how approve/consentId interact and what launch/terminate do to an already-running app, but nothing critical is absent.

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?

At 60% schema coverage the description still contributes meaning: 'boot' binds the device to the session, device is the UDID/name for boot/erase, app is a .app path, service/bundleId apply to privacy_reset, and consent-gated actions imply the role of approve/consentId. It does not explain approve vs consentId explicitly, leaving that pair to inference.

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 concrete verb and resource ('Control an iOS Simulator (macOS)') and then enumerates all nine actions in the schema enum, so an agent can map intent to action without opening the schema. It also explicitly demarcates the boundary with qa_wda ('Structured iOS automation: qa_wda').

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?

Gives clear routing conditions: use qa_wda for structured iOS automation, and poll qa_wait with reason 'simulator_booted' when a cold boot is slow. It also flags that install, privacy_reset and erase are consent-gated, which tells the agent a prerequisite exists. It stops short of stating when NOT to use this tool beyond the qa_wda split.

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