Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy

Launch App (IDB)

idb-launch

Launch iOS apps by bundle ID, stream stdout/stderr, pass arguments, set environment variables, and receive process ID with failure diagnostics.

Instructions

idb-launch

Launch application on iOS target - start apps with optional output streaming and environment control.

Overview

Launches installed applications by bundle ID with optional stdout/stderr streaming, command-line arguments, and environment variables. Extracts process ID for tracking, streams app output when debugging is needed, and provides detailed error guidance for launch failures (app not installed, already running, crashed on launch).

Parameters

Required

  • bundleId (string): App bundle identifier (from idb-list-apps or app installation)

Optional

  • udid (string): Target identifier - auto-detects if omitted

  • streamOutput (boolean): Enable stdout/stderr capture with -w flag

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

  • environment (object): Environment variables to set (KEY=VALUE format)

Returns

Launch status with success indicator, bundle ID, extracted process ID, streaming status, captured stdout/stderr (if streaming enabled), error details if failed, and troubleshooting guidance (app not found, already running, crash logs).

Examples

Simple launch for UI automation

const result = await idbLaunchTool({
  bundleId: 'com.example.MyApp'
});

Launch with debug output streaming

await idbLaunchTool({
  bundleId: 'com.example.MyApp',
  streamOutput: true,
  environment: { DEBUG: '1', LOG_LEVEL: 'verbose' }
});

Launch with arguments

await idbLaunchTool({
  bundleId: 'com.example.MyApp',
  arguments: ['--test-mode', '--skip-intro']
});
  • idb-list-apps: Find bundle ID of installed apps

  • idb-terminate: Stop running app

  • idb-ui-tap: Interact with launched app UI

Notes

  • With -w flag: Streams stdout/stderr (useful for debugging)

  • Without -w: Fire and forget (app runs in background)

  • Returns process ID for tracking app lifecycle

  • Supports command-line arguments and environment variables

  • IDB uses --env KEY=VALUE format for environment variables

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
udidNo
bundleIdYes
argumentsNo
environmentNo
streamOutputNo

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 only provide boolean hintschen; the description fills in real behavioral detail: -w enables stdout/stderr streaming, absence of -w makes it fire-and-forget, process ID is extracted, and failure modes include not installed, already running, and crashed on launch. This goes well beyond the annotations and helps an agent predict side effects.

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 well-structured with a front-loaded summary, parameter table, return details, examples, related tools, and notes. It is somewhat long and has minor overlap between the Returns and Notes sections, but every section contributes meaningful information for an agent.

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?

There is no output schema, yet the description provides a thorough Returns section covering success indicator, bundle ID, process ID, streaming status, captured output, error details, and troubleshooting guidance. It also includes relevant examples and related tools, making the definition complete for a five-parameter tool.

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?

The input schema has 0% description coverage, but the description explains every parameter: bundleId, udid, streamOutput, arguments, and environment. It also clarifies the environment KEY=VALUE format and demonstrates usage through examples. This fully compensates for the bare 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 states the exact operation: launch an application on an iOS target by bundle ID, with optional streaming, arguments, and environment variables. It clearly distinguishes itself from related tools like idb-list-apps and idb-terminate. The verb-resource pair is specific and unambiguous.

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?

The description provides a 'Related Tools' section and multiple examples indicating when to use simple launch, streaming, or argument passing. It does not explicitly state when to prefer idb-launch over the sibling simctl-launch or give exclusion criteria, but the intended usage contexts are clear.

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