XC-MCP: XCode CLI wrapper

Overview Schema Source Related Servers Discussions Admin

Simulate Location

simctl-location

Idempotent

Simulate GPS location on an iOS simulator: set fixed coordinates, use city presets, play GPX scenarios, animate waypoint routes, or clear the override.

Instructions

simctl-location

Simulate GPS location on an iOS simulator — set fixed coordinates, use city presets, play back GPX routes, animate along waypoints, or clear the override.

What it does

Wraps xcrun simctl location <udid> set/clear/start/run/list to give full control over the simulated GPS position. Exactly one action must be specified per call.

Parameters

udid (string, optional): Simulator UDID. Defaults to the booted simulator if omitted.

Actions (exactly one required)

Action	Params	Description
Coordinate	`lat` (number) + `lng` (number)	Set fixed lat/lng
City preset	`city` (string)	Named city from built-in list
GPX scenario	`gpx` (string)	Run a built-in scenario by name
Waypoints	`waypoints` (string) + optional `speed` (number, m/s, default 20)	Animate route
Clear	`clear: true`	Remove location override
List scenarios	`listScenarios: true`	List available GPX scenario names

City Presets

dublin, london, newyork, sanfrancisco, tokyo, sydney, paris, berlin, beijing, mumbai, cairo, saopaulo, losangeles

Aliases also accepted: nyc (→ newyork), sf (→ sanfrancisco), la (→ losangeles)

Coordinate Validation

Latitude: -90 to 90
Longitude: -180 to 180

Waypoints Format

Whitespace-separated lat,lng pairs. At least 2 required.

"53.34,-6.26 51.50,-0.12 48.85,2.35"

Returns

JSON response with action, udid, success, message, action-specific fields, and guidance.

Examples

Set coordinates

await simctlLocationTool({ lat: 53.3498, lng: -6.2603 })

City preset

await simctlLocationTool({ city: 'Dublin' })
await simctlLocationTool({ city: 'nyc' })

GPX scenario

await simctlLocationTool({ gpx: 'FreewayDrive' })

Waypoint animation

await simctlLocationTool({ waypoints: '53.34,-6.26 51.50,-0.12', speed: 10 })

Clear override

await simctlLocationTool({ clear: true })

List scenarios

await simctlLocationTool({ listScenarios: true })

Input Schema

TableJSON Schema

Name	Required	Description	Default
`gpx`	No
`lat`	No
`lng`	No
`city`	No
`udid`	No
`clear`	No
`speed`	No
`waypoints`	No
`listScenarios`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv4.1.0Sep 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds substantial behavioral context: it wraps xcrun simctl location, explains that clear removes the override, specifies coordinate validation, details the waypoints format, and documents the exact return structure. This goes far beyond the annotations and fully discloses the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but meticulously structured with clear section headings (Parameters, City Presets, Coordinate Validation, Waypoints Format, Returns, Examples). It front-loads a concise summary, and every section earns its place by addressing a distinct aspect of the tool. The use of tables and code examples improves scannability without redundancy.

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 (9 parameters, multiple modes, no output schema), the description is remarkably complete. It covers all parameters, validates inputs, explains the return JSON, provides realistic examples, and clarifies constraints like 'exactly one action'. Nothing an agent needs to call the tool correctly is missing.

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 document all 9 parameters. It does so comprehensively with a dedicated table mapping each parameter to its action, including defaults (udid), validation ranges (lat/lng), format specifications (waypoints), and even city aliases. No parameter is left unexplained.

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 clear verb (simulate) and resource (GPS location on an iOS simulator) and enumerates all distinct actions (set coordinates, city presets, GPX routes, waypoint animation, clear, list). It is specific and leaves no ambiguity about the tool's scope, and it naturally stands apart from sibling simctl tools.

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 on how to invoke the tool, including the requirement that exactly one action be specified and the default for udid. It does not explicitly name alternatives or state when not to use it, but given there is no direct sibling for location simulation, the guidance is sufficient. A 4 reflects the absence of explicit exclusion criteria while acknowledging the implied usage.

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

Deploy Server