Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy

Launch App on Simulator

simctl-launch

Start an iOS app on a booted simulator with custom arguments and environment variables, and receive the process ID for tracking and termination.

Instructions

simctl-launch

Launch an iOS app on a simulator with support for custom arguments and environment variables.

What it does

Starts an iOS app on a booted simulator, optionally passing command-line arguments and environment variables. Returns the process ID of the launched app for tracking.

Parameters

  • udid (string, required): Simulator UDID (from simctl-list)

  • bundleId (string, required): App bundle ID (e.g., com.example.MyApp)

  • arguments (string[], optional): Command-line arguments to pass to the app

  • environment (object, optional): Environment variables to set (automatically prefixed with SIMCTL_CHILD_)

Returns

JSON response with:

  • Process ID of the launched app

  • Launch status and command executed

  • Guidance for next steps (terminating, opening URLs, checking container)

Examples

Simple app launch

await simctlLaunchTool({
  udid: 'device-123',
  bundleId: 'com.example.MyApp'
})

Launch with debug arguments

await simctlLaunchTool({
  udid: 'device-123',
  bundleId: 'com.example.MyApp',
  arguments: ['--verbose', '--debug']
})

Launch with environment variables

await simctlLaunchTool({
  udid: 'device-123',
  bundleId: 'com.example.MyApp',
  environment: { DEBUG: '1', API_URL: 'https://staging.example.com' }
})

Common Use Cases

  1. Debug launches: Start app with debug flags enabled

  2. API environment switching: Set staging/production API URLs

  3. Feature flags: Enable experimental features via environment

  4. Test scenarios: Configure app behavior for specific test cases

  5. Deep link testing: Launch app then open URLs with simctl-openurl

Important Notes

  • Simulator must be booted: Use simctl-boot first if simulator is not running

  • App must be installed: Use simctl-install to install app first

  • Environment variables: Automatically prefixed with SIMCTL_CHILD_ for simctl compatibility

  • Process ID tracking: Returned PID can be used to monitor or terminate the app

Error Handling

  • App not installed: Returns error if app bundle is not found

  • Simulator not booted: Indicates simulator must be booted first

  • Invalid bundle ID: Validates bundle ID format (must contain '.')

  • Simulator not found: Validates simulator exists in cache

Next Steps After Launch

  1. Terminate app: simctl-terminate <udid> <bundleId>

  2. Open URL/deep link: simctl-openurl <udid> myapp://deeplink

  3. Check app container: simctl-get-app-container <udid> <bundleId>

  4. Send push notification: simctl-push <udid> <bundleId> <payload>

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
udidYes
bundleIdYes
argumentsNo
environmentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The annotations provide no safety hints (all false), so the description carries the full burden. It discloses that launching is a state-changing operation, returns a process ID, explains environment variable prefixing (SIMCTL_CHILD_), and details error handling and next steps. No contradictions with annotations.

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 description is lengthy but well-structured with clear sections and front-loaded summary. Every section adds value (examples, use cases, errors, next steps). While some redundancy exists (e.g., prerequisites repeated in notes and errors), it remains organized and scannable.

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 the tool's complexity (nested object parameter, no output schema, minimal annotations), the description covers parameters, return format, prerequisites, error conditions, and post-launch actions. An agent has everything needed to invoke it correctly without external references.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate. It explains each parameter, including the origin of udid (from simctl-list), bundleId format, arguments as array, and environment object with automatic prefix. Examples illustrate usage, providing far more meaning than the raw schema.

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 clearly states the tool launches an iOS app on a booted simulator with optional arguments and environment variables, and returns a process ID. It is specific about the resource (simulator/app) and action, and distinct from sibling tools like simctl-install or idb-launch.

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?

A 'Common Use Cases' section lists when to use the tool, and prerequisites (simulator booted, app installed) are explicitly stated. However, it does not explicitly contrast with alternatives like idb-launch or mention when not to use it, so it falls short of full explicitness.

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