Skip to main content
Glama
mgcrea

@mgcrea/mcp-ios-simulator

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

iOS Simulator: Launch

ios_simulator_launch

Launch an installed app. Pass arguments to put it into a fixture or demo mode — that is what IOS_SIMULATOR_LAUNCH_ARGS sets as the default for every launch that does not override it.

Instructions

Launch an installed app. Pass arguments to put it into a fixture or demo mode — that is what IOS_SIMULATOR_LAUNCH_ARGS sets as the default for every launch that does not override it. Standard output and error are captured to files under the output directory, so an app that dies on launch leaves something readable behind. Pass capture_logs: true to also get its Logger/os_log output, in one file read with ios_simulator_read_logs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deviceNoWhich simulator: its UDID or its name as shown by ios_simulator_list. Omit it when exactly one is booted — that is the normal case, and IOS_SIMULATOR_ID pins it when it is not. Unlike simctl's own `booted`, this never picks arbitrarily between two.
argumentsNoLaunch arguments, e.g. ["-DemoMode", "YES"]. Overrides IOS_SIMULATOR_LAUNCH_ARGS rather than adding to it.
bundle_idYesThe app's bundle identifier, e.g. "io.mgcrea.Canopy". List them with ios_simulator_list_apps.
capture_logsNoWrite stdout, stderr and every Logger/os_log message to one fresh file, for ios_simulator_read_logs. Sets OS_ACTIVITY_DT_MODE=YES in the app's environment, which is what Xcode sets to mirror unified logging onto stderr; without it an app's Logger output reaches no file at all.
terminate_firstNoReplace a running copy rather than attaching to it. On by default so a launch means a fresh process and a predictable first screen.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.1
    • addedInput schema / properties / capture_logs
      Added value: +{
+  "default": false,
+  "description": "Write stdout, stderr and every Logger/os_log message to one fresh file, for ios_simulator_read_logs. Sets OS_ACTIVITY_DT_MODE=YES in the app's environment, which is what Xcode sets to mirror unified logging onto stderr; without it an app's Logger output reaches no file at all.",
+  "type": "boolean"
+}
  2. First observedv0.2.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the write-and-safe profile is covered. The description adds meaningful context beyond annotations: stdout/stderr captured to files, terminate_first default behavior, OS_ACTIVITY_DT_MODE env var, and the IOS_SIMULATOR_ID/LAUNCH_ARGS environment defaults. This is richer than annotations alone.

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?

Four sentences, front-loaded with the core action ('Launch an installed app'). Each sentence delivers distinct information (env defaults, log capture, capture_logs semantics). Slight density with env-var references but no filler.

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 launch tool with no output schema, the description covers what is needed: how to pass args, where logs go, how to read them (pointing to ios_simulator_read_logs), and terminate_first behavior. Missing explicit mention of app-not-installed failure mode, but core operational knowledge is present.

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 description coverage is 100%, so the baseline is 3. The description reinforces and contextualizes key parameters — arguments behavior (overrides env default), capture_logs purpose (Logger output to file), and the output directory context — adding narrative that links parameters to the operation's side effects.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Launch an installed app'), which is immediately distinguishable from siblings like ios_simulator_install and ios_simulator_terminate. It doesn't explicitly name the closest alternative (ios_simulator_terminate or ios_simulator_restart_wda), but the action is unambiguous.

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

Usage Guidelines3/5

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

The description explains how to use key features (arguments for fixture mode, capture_logs for logging) but never states when to use this tool versus ios_simulator_terminate, ios_simulator_restart_wda, or ios_simulator_open_url. Usage is implied through the feature descriptions rather than explicit routing guidance.

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