Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Install App (IDB)

idb-install
Idempotent

Deploy .app bundles or .ipa archives to iOS devices or simulators, with auto-detection of target and troubleshooting guidance.

Instructions

idb-install

Install application to iOS target - deploy .app bundles or .ipa archives for testing.

Overview

Transfers and registers application bundles (.app) or archives (.ipa) to iOS targets. Validates app path format before transfer, handles installation process (transfer, registration, signature validation), extracts bundle ID from output for launching, and provides detailed error guidance for common failures (code signing, architecture mismatch, already installed).

Parameters

Required

  • appPath (string): Absolute path to .app bundle or .ipa archive

Optional

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

Returns

Installation status with success indicator, app path, extracted bundle ID (if available), installation output, and context-specific troubleshooting guidance (code signing issues, architecture mismatches, already installed, file not found).

Examples

Install simulator build

const result = await idbInstallTool({
  appPath: '/path/to/DerivedData/Build/Products/Debug-iphonesimulator/MyApp.app'
});

Install signed IPA to physical device

await idbInstallTool({
  appPath: '/path/to/MyApp.ipa',
  udid: 'DEVICE-UDID-123'
});

Related Tools

  • idb-list-apps: Find bundle ID after installation

  • idb-launch: Launch installed app by bundle ID

  • idb-uninstall: Remove app for clean reinstall

Notes

  • Supports .app bundles (from Xcode build) and .ipa archives (signed/unsigned)

  • Installation can take 10-60 seconds depending on app size

  • Simulators accept unsigned .app bundles

  • Physical devices require valid provisioning profile

  • Auto-terminates running apps before installation

  • Extracts bundle ID from output when available

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
udidNo
appPathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, and the description adds meaningful behavioral context: it validates app path format before transfer, auto-terminates running apps before installation, extracts bundle ID from output, and can take 10-60 seconds. It also discloses failure modes (code signing, architecture mismatch, already installed) with troubleshooting guidance. This goes beyond what annotations provide.

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 clear sections (Overview, Parameters, Returns, Examples, Related Tools, Notes) and front-loads the core purpose. It is somewhat long, but every section earns its place by covering installation behavior, examples, and troubleshooting. The Notes section is slightly redundant with the Overview but still adds operational details.

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 2-parameter tool with no output schema, the description is quite complete: it covers input formats, target selection, return values, timing, platform constraints, and failure guidance. The only minor gap is that it doesn't describe the exact output schema or error response structure, but the prose description of returns is sufficient for an agent to invoke and interpret the result.

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 0%, so the description carries the full burden. It explains appPath as an absolute path to .app or .ipa, and udid as a target identifier that auto-detects if omitted. This adds real meaning beyond the bare schema properties, though it doesn't specify udid format or how auto-detection resolves ambiguity.

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 a specific verb ('Install'), resource ('application to iOS target'), and the exact artifact types (.app bundles or .ipa archives). It clearly distinguishes from siblings like simctl-install and idb-launch by focusing on the transfer/registration/validation workflow.

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 clear context for when to use this tool (deploying .app or .ipa for testing) and notes platform differences (simulators accept unsigned .app, physical devices require provisioning). It doesn't explicitly say 'use simctl-install instead for X' or list exclusions, but the Related Tools section routes to idb-list-apps, idb-launch, and idb-uninstall for adjacent steps.

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