What can you do with this server?

The xcode-mcp server provides comprehensive programmatic control over Xcode development tools for iOS simulator management, UI automation, and build processes via Claude Desktop. iOS Simulator Management (simctl): * List and discover simulators (devices, device types, runtimes, pairs) with optional search filtering * Boot and shutdown simulators (individual or all at once) * Install, launch, terminate, and uninstall apps with support for launch arguments and debugger attachment * Open URLs or deep links for testing app integrations * Send push notifications with custom payloads * Set or clear simulated GPS coordinates for location-based testing * Manage privacy permissions (grant, revoke, reset) for camera, microphone, location, contacts, photos, etc. * Capture screenshots in multiple formats (PNG, JPEG, TIFF) with optional masking * Accept device UDIDs, human-readable names (e.g., "iPhone 16 Pro"), or "booted" keyword for flexibility UI Automation (wda via WebDriverAgent): * Check server connectivity * Perform tap gestures by coordinates, accessibility ID, or element ID * Type text into input fields * Execute swipe gestures * Find UI elements using various strategies * Retrieve complete UI hierarchy as XML * Simulate pressing the home button * Accept or dismiss system alerts Xcode Build Management (xcodebuild): * List schemes, targets, and configurations for projects/workspaces * Build project schemes for specific destinations and configurations * Run tests with structured results * Clean build artifacts * Display build configuration settings Key Use Cases: Automated testing workflows, UI/UX testing, screenshot generation, location-based feature testing, push notification verification, privacy permission testing, deep link validation, and CI/CD pipeline simulator management.

Which integrations are available for this server?

Provides comprehensive control over iOS simulator devices, enabling app installation and uninstallation, push notification testing, location simulation, and management of privacy permissions. Integrates with Xcode's command-line tools (simctl) to manage the lifecycle of iOS simulators, including booting, shutting down, and capturing device screenshots.

How do I use xcode-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@xcode-mcp Take a screenshot of the booted simulator" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

xcode-mcp

by obj-p

Overview Schema Related Servers Score Discussions

TypeScript

Local

xcode-mcp

MCP server for Xcode developer tools.

Installation

npm install
npm run build

Usage

Claude Desktop Configuration

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "xcode": {
      "command": "node",
      "args": ["/Users/YOUR_USERNAME/Projects/xcode-mcp/dist/index.js"]
    }
  }
}

Available Tools

iOS Simulator (`simctl`)

Control iOS Simulators via xcrun simctl.

Tool	Description
`simctl_list`	List available simulators, device types, runtimes, or device pairs
`simctl_boot`	Boot a simulator device
`simctl_shutdown`	Shutdown a simulator device or all simulators
`simctl_install`	Install an app bundle on a simulator
`simctl_launch`	Launch an app on a simulator
`simctl_terminate`	Terminate a running app without shutting down the simulator
`simctl_uninstall`	Uninstall an app from a simulator
`simctl_openurl`	Open a URL or deep link on a simulator
`simctl_push`	Send a push notification to an app
`simctl_location`	Set or clear the simulated GPS location
`simctl_privacy`	Grant, revoke, or reset privacy permissions for an app
`simctl_io_screenshot`	Capture a screenshot from a simulator

Device Identification

All simulator tools that require a device accept:

Device UDID (e.g., "3A8C9B5F-1234-5678-9ABC-DEF012345678")
Device name (e.g., "iPhone 16 Pro")
Special value "booted" for the currently booted simulator

Examples

List all devices:

{"name": "simctl_list", "arguments": {"filter": "devices"}}

Boot a simulator:

{"name": "simctl_boot", "arguments": {"device": "iPhone 16 Pro"}}

Take a screenshot:

{"name": "simctl_io_screenshot", "arguments": {"device": "booted"}}

Send a push notification:

{
  "name": "simctl_push",
  "arguments": {
    "device": "booted",
    "bundle_id": "com.example.app",
    "payload": {
      "aps": {
        "alert": {
          "title": "Test",
          "body": "Hello from MCP!"
        }
      }
    }
  }
}

Set location:

{
  "name": "simctl_location",
  "arguments": {
    "device": "booted",
    "action": "set",
    "latitude": 37.7749,
    "longitude": -122.4194
  }
}

Grant camera permission:

{
  "name": "simctl_privacy",
  "arguments": {
    "device": "booted",
    "action": "grant",
    "service": "camera",
    "bundle_id": "com.example.app"
  }
}

WebDriverAgent (`wda`)

UI automation for iOS Simulator apps via WebDriverAgent. Enables tapping, swiping, typing, and finding UI elements.

Tool	Description
`wda_status`	Check WebDriverAgent server connectivity
`wda_tap`	Tap at coordinates, by accessibility ID, or element ID
`wda_type`	Type text into the currently focused text field
`wda_swipe`	Perform a swipe gesture from start to end coordinates
`wda_find`	Find UI elements by accessibility ID, class name, or predicate
`wda_source`	Get the UI hierarchy (accessibility tree) as XML
`wda_home`	Press the home button
`wda_alert`	Accept or dismiss system alerts

Prerequisites

Clone WebDriverAgent (one-time):

git clone https://github.com/appium/WebDriverAgent.git
cd WebDriverAgent

Start WDA on a simulator (keep running in a terminal):

xcodebuild test -project WebDriverAgent.xcodeproj \
  -scheme WebDriverAgentRunner \
  -destination 'platform=iOS Simulator,name=iPhone 16 Pro'

Verify WDA is running:
```
curl http://localhost:8100/status
```

Coordinate System

All coordinates are in points (logical pixels), not physical pixels. Use wda_source to see element positions in the UI hierarchy XML.

Common Parameters

All WDA tools accept these optional parameters:

bundle_id: Activate a specific app before the action
port: WDA server port (default: 8100)

Examples

Check WDA status:

{"name": "wda_status", "arguments": {}}

Tap at coordinates:

{"name": "wda_tap", "arguments": {"x": 200, "y": 400}}

Tap by accessibility ID:

{"name": "wda_tap", "arguments": {"accessibility_id": "login_button"}}

Tap with app activation:

{"name": "wda_tap", "arguments": {"accessibility_id": "login", "bundle_id": "com.example.app"}}

Type text:

{"name": "wda_type", "arguments": {"text": "hello@example.com"}}

Swipe down (scroll up):

{
  "name": "wda_swipe",
  "arguments": {
    "start_x": 200,
    "start_y": 400,
    "end_x": 200,
    "end_y": 200,
    "duration": 500
  }
}

Find elements:

{"name": "wda_find", "arguments": {"strategy": "accessibility id", "value": "submit_button"}}

Get UI hierarchy:

{"name": "wda_source", "arguments": {}}

Handle alert:

{"name": "wda_alert", "arguments": {"action": "accept"}}

Xcode Build (`xcodebuild`)

Build, test, and manage Xcode projects via xcodebuild.

Tool	Description
`xcodebuild_list`	List schemes, targets, and configurations for a project or workspace
`xcodebuild_build`	Build a scheme for a destination with structured result parsing
`xcodebuild_test`	Run tests and return structured results with pass/fail counts
`xcodebuild_clean`	Clean build artifacts for a scheme
`xcodebuild_show_build_settings`	Show build configuration settings

Project Auto-Detection

All xcodebuild tools can automatically detect the project or workspace in the current directory. They prefer .xcworkspace over .xcodeproj. You can also specify explicit paths:

workspace: Path to a .xcworkspace file
project: Path to a .xcodeproj file
directory: Directory to search for projects (defaults to cwd)

Destination Handling

The destination parameter accepts:

Device names (e.g., "iPhone 16 Pro") - automatically resolved to simulator UDID
Full destination strings (e.g., "platform=iOS Simulator,name=iPhone 16 Pro")

Examples

List schemes:

{"name": "xcodebuild_list", "arguments": {}}

Build a scheme:

{
  "name": "xcodebuild_build",
  "arguments": {
    "scheme": "MyApp",
    "destination": "iPhone 16 Pro",
    "configuration": "Debug"
  }
}

Run tests:

{
  "name": "xcodebuild_test",
  "arguments": {
    "scheme": "MyApp",
    "destination": "iPhone 16 Pro",
    "only_testing": ["MyAppTests/testLogin"]
  }
}

Clean build:

{
  "name": "xcodebuild_clean",
  "arguments": {
    "scheme": "MyApp"
  }
}

Show build settings:

{
  "name": "xcodebuild_show_build_settings",
  "arguments": {
    "scheme": "MyApp",
    "configuration": "Release"
  }
}

Development

# Run in development mode
npm run dev

# Build
npm run build

# Test
npm test

License

MIT

Available Tools

12 tools

simctl_bootC

Boot a simulator device

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Device UDID or name to boot

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('boot') but doesn't explain what booting entails (e.g., starting a virtual device, potential delays, or system requirements), nor does it cover error conditions or side effects, leaving significant gaps.

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 extremely concise with a single sentence 'Boot a simulator device', which is front-loaded and wastes no words. Every part of the sentence directly contributes to understanding the tool's purpose, making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of booting a simulator device (a mutation operation with no annotations or output schema), the description is incomplete. It lacks details on behavioral traits, success indicators, or error handling, which are crucial for an agent to use this tool effectively in context with its siblings.

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

Parameters3/5

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

The input schema has 100% description coverage, with the 'device' parameter documented as 'Device UDID or name to boot'. The description adds no additional meaning beyond this, but since schema coverage is high, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Boot a simulator device' clearly states the action (boot) and target resource (simulator device), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'simctl_shutdown' or 'simctl_launch' which also operate on simulator devices, missing explicit distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., device must be shut down), exclusions, or how it differs from related tools like 'simctl_launch' or 'simctl_shutdown', leaving the agent without context for selection.

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

simctl_installC

Install an app bundle on a simulator

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Device UDID, name, or "booted"
`app_path`	Yes	Path to the .app bundle to install

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden but adds minimal behavioral context. It states the action ('Install') but doesn't disclose traits like whether it overwrites existing apps, requires specific simulator states (e.g., booted), handles errors, or has side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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 a single, efficient sentence that front-loads the core action without unnecessary words. Every word earns its place by directly conveying the tool's function, making it easy to parse quickly. No fluff or redundancy is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, error handling, prerequisites (e.g., simulator state), and what happens post-installation. For a tool that modifies simulator state, this leaves critical gaps for an AI agent to use it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, with both parameters ('device' and 'app_path') well-documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain format details or usage examples). Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate or enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Install') and resource ('app bundle on a simulator'), making the purpose immediately understandable. It distinguishes from siblings like 'simctl_uninstall' (removal) and 'simctl_launch' (execution), though it doesn't explicitly mention these distinctions. The specificity is good but could be slightly enhanced by noting it's for iOS/macOS simulators.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the simulator must be booted, which might be inferred from sibling 'simctl_boot'), exclusions, or comparisons to tools like 'simctl_launch' (which might start an installed app). This lack of context leaves the agent to guess based on tool names alone.

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

simctl_io_screenshotC

Capture a screenshot from a simulator

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Device UDID, name, or "booted"
`output_path`	No	Path to save the screenshot. If omitted, returns base64 image data
`type`	No	Image format (default: png)	png
`mask`	No	Mask to apply for non-rectangular displays

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core action ('Capture a screenshot') but lacks critical details: it doesn't specify if this requires simulator boot state, mention error conditions (e.g., if device isn't found), describe output handling (e.g., base64 format when output_path is omitted), or note any side effects. For a tool with no annotation coverage, this is a significant gap in transparency.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse. Every word earns its place, with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a screenshot tool with 4 parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain the return behavior (e.g., base64 data when output_path is omitted), error handling, or dependencies like simulator state. For a tool that interacts with device state and has multiple options, more context is needed to guide effective use.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all parameters (device, output_path, type, mask) with descriptions and enums. The description adds no parameter-specific information beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Capture a screenshot') and target resource ('from a simulator'), which is specific and unambiguous. It distinguishes this tool from siblings like simctl_boot or simctl_install by focusing on visual capture rather than device management or app operations. However, it doesn't explicitly differentiate from potential similar tools (e.g., if there were a simctl_record_video), though none exist in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the simulator must be running), exclusions (e.g., not for physical devices), or compare to other screenshot methods. This leaves the agent to infer usage from the tool name and context alone.

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

simctl_launchC

Launch an app on a simulator

ParametersJSON Schema

Name	Required	Description
`device`	Yes	Device UDID, name, or "booted"
`bundle_id`	Yes	Bundle identifier of the app to launch
`args`	No	Optional arguments to pass to the app
`wait_for_debugger`	No	Wait for debugger to attach before launching
`console_pty`	No	Connect stdout/stderr to the current terminal

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the action ('Launch') but doesn't disclose behavioral traits such as error conditions (e.g., if the app isn't installed), side effects, or what happens on success/failure. This leaves significant gaps for a mutation tool.

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 a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's purpose, making it easy to scan and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a mutation with 5 parameters, no annotations, and no output schema), the description is inadequate. It lacks details on behavior, error handling, and output, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description doesn't add any meaning beyond the schema, such as explaining parameter interactions or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Launch') and target ('an app on a simulator'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like simctl_terminate (which stops apps) or simctl_install (which installs apps), missing explicit sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a booted simulator or installed app), exclusions, or comparisons to siblings like simctl_terminate for stopping apps or simctl_openurl for opening URLs.

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

simctl_listC

List available simulators, device types, runtimes, or device pairs

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No	Filter to show only specific category
`search`	No	Optional search term to filter results

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the action 'List' but doesn't disclose behavioral traits such as output format (e.g., list of objects, JSON structure), pagination, rate limits, or error conditions. The description is minimal and lacks necessary context for safe and effective use.

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 a single, efficient sentence with zero waste. It front-loads the purpose and lists all relevant resource types without unnecessary words, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., structured data, plain text), how results are formatted, or any dependencies. For a tool with 2 parameters and no structured output info, more context is needed to ensure proper usage.

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

Parameters3/5

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

Schema description coverage is 100%, with clear descriptions for both parameters. The description mentions 'Filter to show only specific category' implicitly through the listed resources, but adds no additional meaning beyond the schema's enum values and search term explanation. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and specifies the resources: 'available simulators, device types, runtimes, or device pairs'. It distinguishes from siblings like 'boot', 'install', or 'launch' by focusing on listing rather than actions, but doesn't explicitly differentiate from potential similar listing tools (though none exist in siblings).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives is provided. The description lists what it does but doesn't specify context, prerequisites, or exclusions. For example, it doesn't mention if this should be used before booting a simulator or to check available options.

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

simctl_locationB

Set or clear the simulated GPS location on a simulator

ParametersJSON Schema

Name	Required	Description
`device`	Yes	Device UDID, name, or "booted"
`action`	Yes	Action to perform: set a location or clear it
`latitude`	No	Latitude coordinate (required when action is "set")
`longitude`	No	Longitude coordinate (required when action is "set")

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the basic action without disclosing behavioral traits like permission requirements, side effects (e.g., impact on simulator state), or error handling. It lacks details on what 'clear' entails or how location changes persist.

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 a single, efficient sentence with zero waste—front-loaded and directly states the tool's purpose. Every word earns its place, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete for a mutation tool with 4 parameters. It doesn't explain return values, error conditions, or behavioral nuances, leaving gaps in understanding the tool's full context and effects.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond implying latitude/longitude are for 'set' actions, which is already covered in schema descriptions. Baseline score of 3 is appropriate as schema does the heavy lifting.

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 specific action ('set or clear') and resource ('simulated GPS location on a simulator'), distinguishing it from siblings like boot, install, or screenshot tools. It precisely defines the tool's function without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for location simulation on simulators but doesn't explicitly state when to use this versus alternatives (e.g., other simctl tools for different operations). No guidance on prerequisites or exclusions is provided, leaving usage context partially inferred.

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

simctl_openurlC

Open a URL or deep link on a simulator

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Device UDID, name, or "booted"
`url`	Yes	URL or deep link to open

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the action ('Open') but doesn't disclose behavioral traits such as what happens if the simulator isn't running, whether this requires specific permissions, error conditions, or the expected outcome (e.g., opens in browser vs. app). For a mutation tool with zero annotation coverage, this is insufficient.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a mutation tool with no annotations and no output schema), the description is incomplete. It doesn't explain what 'Open' entails behaviorally, potential side effects, error handling, or return values. For a tool that interacts with simulators, more context is needed to use it effectively.

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

Parameters3/5

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

Schema description coverage is 100%, with clear descriptions for both parameters (device and url). The description doesn't add any meaning beyond what the schema provides (e.g., no examples of deep link formats or device selection strategies). Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Open') and target ('a URL or deep link on a simulator'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like simctl_launch (which might launch apps) or simctl_push (which might push notifications), but the specific focus on URLs provides reasonable differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a booted simulator), exclusions, or relationships with sibling tools like simctl_launch (for app launching) or simctl_boot (for starting simulators). The description assumes context without providing usage context.

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

simctl_privacyB

Grant, revoke, or reset privacy permissions for an app on a simulator

ParametersJSON Schema

Name	Required	Description
`device`	Yes	Device UDID, name, or "booted"
`action`	Yes	Action to perform on the permission
`service`	Yes	The privacy service/permission to modify
`bundle_id`	Yes	Bundle identifier of the app

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the actions (grant/revoke/reset) but doesn't cover critical aspects like required permissions, side effects (e.g., app restart), error conditions, or what 'reset' entails. This is inadequate for a mutation tool with zero annotation coverage.

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 a single, efficient sentence that front-loads the core functionality. Every word earns its place, with no redundancy or wasted phrasing. It's appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about behavioral traits (e.g., side effects, error handling), usage context, and return values. The 100% schema coverage helps but doesn't compensate for missing behavioral context.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain 'service' enum values or 'device' formats). Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific verb ('grant, revoke, or reset') and resource ('privacy permissions for an app on a simulator'), distinguishing it from sibling tools like simctl_install or simctl_launch. It precisely defines the tool's scope without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., simulator must be running), exclusions, or how it differs from other privacy-related tools. Usage context is implied but not explicit.

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

simctl_pushC

Send a push notification to an app on a simulator

ParametersJSON Schema

Name	Required	Description
`device`	Yes	Device UDID, name, or "booted"
`bundle_id`	Yes	Bundle identifier of the app to receive the push
`payload`	Yes	Push notification payload (file path or JSON object)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't mention side effects (e.g., whether the notification triggers app behavior), permissions needed, or error conditions (e.g., invalid device or bundle ID). This is a significant gap for a mutation tool with zero annotation coverage.

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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It earns its place by clearly stating the tool's function, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of sending push notifications (a mutation operation), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, or return values, which are crucial for an agent to use this tool effectively in a simulator environment.

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

Parameters3/5

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

The schema description coverage is 100%, so the schema already documents all three parameters (device, bundle_id, payload) with clear descriptions. The description adds no additional meaning beyond what's in the schema, such as examples or constraints, resulting in a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('send a push notification'), target resource ('to an app on a simulator'), and distinguishes from siblings like simctl_install or simctl_launch by focusing on push notifications. However, it doesn't explicitly differentiate from other notification-related tools (none in the sibling list), so it's not a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as simctl_launch for app startup or simctl_openurl for URL handling. It lacks context about prerequisites (e.g., simulator must be running) or exclusions, leaving the agent to infer usage from the tool name alone.

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

simctl_shutdownB

Shutdown a simulator device or all simulators

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Device UDID, name, or "all" to shutdown all simulators

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the action ('Shutdown') but does not disclose behavioral traits such as whether this requires specific permissions, if it's reversible, what happens to running apps, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap.

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 a single, efficient sentence that front-loads the core action and scope. Every word earns its place, with no redundancy or unnecessary details, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a shutdown operation (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It lacks details on permissions, reversibility, error handling, or return values, which are crucial for safe and effective use.

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

Parameters3/5

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

The schema description coverage is 100%, with the parameter 'device' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain UDID formats or side effects). Baseline 3 is appropriate when the schema does the heavy lifting.

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 action ('Shutdown') and the target ('a simulator device or all simulators'), using specific verbs and resources. It distinguishes itself from siblings like 'simctl_boot' (which starts devices) and 'simctl_terminate' (which stops apps, not devices), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for shutting down simulators, but does not explicitly state when to use this tool versus alternatives like 'simctl_terminate' (for apps) or 'simctl_list' (for checking status). It provides basic context but lacks explicit guidance on exclusions or prerequisites.

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

simctl_terminateA

Terminate a running app on a simulator without shutting down the simulator

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Device UDID, name, or "booted"
`bundle_id`	Yes	Bundle identifier of the app to terminate

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool's destructive nature (terminating an app) and specifies the behavioral constraint of not shutting down the simulator. However, it doesn't mention error conditions, permission requirements, or what happens if the app isn't running.

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 a single, efficient sentence that communicates the core purpose and key behavioral constraint without any wasted words. It's front-loaded with the main action and immediately clarifies the scope limitation.

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 destructive tool with no annotations and no output schema, the description provides adequate context about what the tool does and its behavioral constraint. However, it doesn't mention what happens on success/failure or potential side effects, which would be helpful for a termination operation.

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

Parameters3/5

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

With 100% schema description coverage, the input schema already documents both parameters thoroughly. The description doesn't add any additional semantic information about the parameters beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting.

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 specific action ('terminate a running app') and the resource ('on a simulator'), while explicitly distinguishing it from the sibling tool 'simctl_shutdown' by noting it operates 'without shutting down the simulator'. This provides precise differentiation from related 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 for when to use this tool (to terminate an app while keeping the simulator running), but doesn't explicitly mention when NOT to use it or name specific alternatives. It implies usage relative to 'simctl_shutdown' but doesn't provide explicit exclusion criteria.

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

simctl_uninstallC

Uninstall an app from a simulator

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Device UDID, name, or "booted"
`bundle_id`	Yes	Bundle identifier of the app to uninstall

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the action but lacks critical behavioral details: whether this requires specific permissions, if it's destructive (likely yes, but not confirmed), error conditions, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.

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 a single, direct sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately scannable and efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral risks, success indicators, or error handling. For a tool that performs a potentially destructive action, more context is needed to ensure safe and correct usage.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying 'bundle_id' identifies the app and 'device' targets a simulator. Since the schema already covers this, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('uninstall') and target ('app from a simulator'), making the purpose immediately understandable. It distinguishes from siblings like 'simctl_install' by specifying the opposite operation. However, it doesn't explicitly mention the specific simulator context beyond the tool name, which slightly limits differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a booted simulator), exclusions, or relationships with sibling tools like 'simctl_terminate' or 'simctl_shutdown'. The agent must infer usage from context alone.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

12 tool updatesv1.0.0Jan 24, 2026
- First observedsimctl_boot
- First observedsimctl_install
- First observedsimctl_io_screenshot
- First observedsimctl_launch
- First observedsimctl_list
- First observedsimctl_location
- First observedsimctl_openurl
- First observedsimctl_privacy
- First observedsimctl_push
- First observedsimctl_shutdown
- First observedsimctl_terminate
- First observedsimctl_uninstall

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific simulator operations like booting, installing, screenshotting, launching, listing, location setting, URL opening, privacy management, push notifications, shutdown, termination, and uninstallation. There is no ambiguity or overlap between these functions.

Naming Consistency5/5

All tools follow a consistent 'simctl_verb' or 'simctl_verb_noun' pattern (e.g., simctl_boot, simctl_install, simctl_io_screenshot), with no deviations in style or convention. This makes the tool set highly predictable and readable.

Tool Count5/5

With 12 tools, the server is well-scoped for managing Xcode simulators, covering essential operations from device control to app testing. Each tool earns its place without being excessive or insufficient for the domain.

Completeness5/5

The tool set provides comprehensive coverage for simulator management, including device lifecycle (boot/shutdown), app lifecycle (install/launch/terminate/uninstall), testing features (screenshot, location, URL, push), and configuration (privacy, list). There are no obvious gaps that would hinder agent workflows.

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AgentCloud — Hosted iOS Simulator MCP
so.agentcloud
Build, run, and inspect iOS apps in disposable hosted Simulators from cloud coding agents.
Code Execution Testing & QA Tools
1
Limrun
com.limrun
Cloud iOS simulators and Android emulators your agent can create, drive, and throw away.
Cloud Platforms Testing & QA Tools Virtualization
1
mobilerun
io.github.droidrun
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Testing & QA Tools App Automation
38,854
metarun
dev.metarun
Run App Store Connect from your IDE: pricing, listings, screenshots, releases, AI visibility.
Developer Tools Marketing
2

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/obj-p/xcode-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

xcode-mcp

Installation

Usage

Claude Desktop Configuration

Available Tools

iOS Simulator (simctl)

Device Identification

Examples

WebDriverAgent (wda)

Prerequisites

Coordinate System

Common Parameters

Examples

Xcode Build (xcodebuild)

Project Auto-Detection

Destination Handling

Examples

Development

License

Available Tools

Tool Schema Changelog

Resources

Looking for Admin?

Related MCP Connectors

Latest Blog Posts

MCP directory API

iOS Simulator (`simctl`)

WebDriverAgent (`wda`)

Xcode Build (`xcodebuild`)