Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create Simulator

simctl-create

Create iOS simulator devices for testing by specifying device type and optional runtime, defaulting to the latest iOS.

Instructions

simctl-create

Create new iOS simulator devices dynamically.

Overview

Creates a new iOS simulator device with specified device type and runtime version. Automatically validates device types and runtimes against available options, defaulting to the latest iOS version if no runtime is specified. Supports all device types including iPhone, iPad, Apple Watch, and Apple TV.

Parameters

Required

  • name (string): Display name for the new simulator (e.g., "MyTestDevice")

  • deviceType (string): Device type identifier (e.g., "iPhone 16 Pro", "iPad Pro")

Optional

  • runtime (string): iOS/runtime version (e.g., "17.0") - defaults to latest available

Returns

Creation status with new device UDID, device type, runtime version, success indicator, command output, and guidance for next steps (boot, delete, erase).

Examples

Create iPhone with latest iOS

await simctlCreateTool({
  name: "TestiPhone",
  deviceType: "iPhone 16 Pro"
});

Create iPad with specific iOS version

await simctlCreateTool({
  name: "TestiPad",
  deviceType: "iPad Pro (12.9-inch)",
  runtime: "17.0"
});

Related Tools

  • simctl-list: See available device types and runtimes

  • simctl-boot: Boot newly created device

  • simctl-delete: Remove created device when done

Notes

  • Device types: iPhone, iPad, Apple Watch, Apple TV

  • Runtime defaults to latest available iOS version

  • Created device persists until explicitly deleted

  • UDID is auto-generated and returned in response

  • Useful for CI/CD pipelines and automated testing

  • Device type can be partial match (e.g., "iPhone 16" matches "iPhone 16 Pro")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
runtimeNo
deviceTypeYes

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 description goes well beyond the annotations by disclosing that device types and runtimes are automatically validated, that runtime defaults to the latest iOS version, that the device persists until explicitly deleted, and that UDID is auto-generated. It also documents partial device type matching behavior. These are meaningful behavioral details the structured annotations do not convey.

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, examples, and front-loaded overview. It is longer than strictly necessary and contains minor repetition, such as listing supported device types both in the overview and in the notes. Overall, the organization makes it easy for an agent to scan and extract relevant information.

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 three parameters and no output schema, the description provides a complete picture: what the tool does, parameter semantics, expected return fields, usage examples, related tools, and persistence caveats. An agent has enough information to invoke it correctly and anticipate the result without needing additional external context.

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 carries full responsibility for parameter meaning. It clearly defines each parameter: name as display name, deviceType as identifier, runtime as version with default behavior. Examples show realistic values for all parameters, including a partial-match device type note, fully compensating for the empty schema descriptions.

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 it creates new iOS simulator devices with a specific device type and runtime. It distinguishes this tool from siblings like simctl-boot, simctl-delete, and simctl-list by describing creation and lifecycle context. The verb 'create' and resource 'simulator device' are 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 overview explains when to use the tool and the Related Tools section explicitly routes agents to simctl-list for available types/runtimes, simctl-boot for booting, and simctl-delete for removal. It gives strong context, though it does not explicitly state 'when not to use this tool' with hard exclusion criteria. The CI/CD automation note adds practical usage context.

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