What can you do with this server?

This server enables programmatic control of iOS simulators through the Model Context Protocol (MCP), supporting both direct UDID-based and session-based management. Simulator Management (Direct UDID): * List all available simulators (list-available-simulators) and booted simulators (list-booted-simulators) * Boot (boot-simulator-by-udid) or shut down (shutdown-simulator-by-udid) a simulator by UDID Session-Based Management: * Create a new simulator session with optional device name, platform version, timeout, and autoboot settings (create-simulator-session) * List all active sessions (list-simulator-sessions) * Shut down a session's simulator (shutdown-simulator) or fully terminate a session with cleanup (terminate-simulator-session) Application Management: * Install an app by path (install-app), launch by bundle ID (launch-app), and terminate a running app (terminate-app) — all scoped to a session Interaction: * Tap at specified (x, y) coordinates on the simulator screen (tap) * Take screenshots of the simulator screen

Which integrations are available for this server?

Built on top of appium-ios-simulator to provide iOS simulator interaction capabilities for controlling simulator lifecycle and performing actions. Allows programmatic control of iOS simulators, including starting, stopping, booting, installing and launching apps, taking screenshots, and performing taps on coordinates. Interacts with Xcode's iOS simulator infrastructure to manage simulator instances and perform operations on iOS devices.

How do I use MCP Server for iOS Simulator?

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., "@MCP Server for iOS Simulator boot the iPhone 16 simulator on iOS 18.2" 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.

de en es ja ko ru zh

MCP Server for iOS Simulator

by atom2ueki

Overview Schema Related Servers Score Discussions

TypeScript

Local

📱 MCP Server for iOS Simulator

A server that implements the Model Context Protocol (MCP) for iOS simulators, built on top of appium-ios-simulator and utilizing the MCP TypeScript SDK.

📋 Overview

This project provides a bridge between iOS simulators and the Model Context Protocol, allowing for standardized communication with iOS simulator instances. It enables programmatic control of iOS simulators while leveraging the MCP protocol for consistent interfaces across different environments. The server utilizes stdio as its transport mechanism, making it ideal for integration with Claude Desktop and other MCP-compatible clients.

Related MCP server: Simulator MCP

🎬 Demo

iOS Simulator Demo

Demo showing how to boot an iOS simulator using Claude AI Desktop

🏗️ Architecture

The server consists of three main components:

🔄 Simulator Management Layer - Handles iOS simulator lifecycle and interactions
🔌 MCP Protocol Implementation - Implements the Model Context Protocol using the TypeScript SDK with stdio transport
📊 Logger Component - Provides file-based logging without interfering with the stdio transport

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  MCP Protocol   │     │     Stdio       │     │    Simulator    │
│  Implementation │◄────┤    Transport    │◄────┤   Management    │
│                 │     │                 │     │      Layer      │
└─────────────────┘     └─────────────────┘     └─────────────────┘
        ▲                                                ▲
        │                                                │
        ▼                                                ▼
┌─────────────────┐                             ┌─────────────────┐
│   MCP Client    │                             │  iOS Simulator  │
│  (e.g. Claude)  │                             │                 │
└─────────────────┘                             └─────────────────┘

✨ Features

🚀 Start, stop, and manage iOS simulator instances
🔌 Boot and shutdown simulators
📲 Install and launch applications on simulators
📸 Take screenshots of simulator screens
👆 Perform taps on coordinates
🔄 Support for multiple concurrent simulator sessions
📝 Comprehensive file-based logging without console output
🛡️ Error-resilient operation

📋 Prerequisites

🟢 Node.js (v16 or later)
🍎 macOS (required for iOS simulators)
🛠️ Xcode with iOS simulators installed
📜 TypeScript 4.5+

🔧 Installation

Installing via Smithery

To install iOS Simulator Control Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @atom2ueki/mcp-server-ios-simulator --client claude

Manual Installation

# Clone the repository
git clone https://github.com/atom2ueki/mcp-server-ios-simulator.git
cd mcp-server-ios-simulator

# Install dependencies
npm install

🐳 Docker

A Dockerfile is provided so the server can be packaged for the Glama MCP directory and other container hosts.

docker build -t mcp-server-ios-simulator .
docker run --rm -i mcp-server-ios-simulator

Note: iOS simulators only run on macOS, so a Linux container can host the MCP process and respond on stdio but cannot drive a real simulator. The container is intended for portability checks and remote MCP environments that bridge to a macOS host.

⚙️ Configuration

Configuration is handled through the src/config.ts file:

const config = {
  simulator: {
    defaultDevice: process.env.SIMULATOR_DEFAULT_DEVICE || 'iPhone 16',
    defaultOS: process.env.SIMULATOR_DEFAULT_OS || '18.2',
    timeout: parseInt(process.env.SIMULATOR_TIMEOUT || '30000', 10),
  }
};

You can customize these settings by setting environment variables:

SIMULATOR_DEFAULT_DEVICE=iPhone 16
SIMULATOR_DEFAULT_OS=18.2
SIMULATOR_TIMEOUT=30000

🚀 Usage

🔨 Building and Starting the Server

# Build the project
npm run build

# Start the server
npm start

🧰 MCP Tools

The server provides two distinct approaches for controlling iOS simulators:

📱 Direct Simulator Management (Recommended)

These tools work directly with simulator UDIDs and don't require maintaining sessions:

📋 list-available-simulators - List all available simulators with their UDIDs
▶️ boot-simulator-by-udid - Boot a simulator directly using its UDID
⏹️ shutdown-simulator-by-udid - Shutdown a simulator directly using its UDID
📊 list-booted-simulators - List all currently booted simulators

Use this approach when: You just want to boot, use, and shut down simulators directly.

📱 Session-Based Management (Advanced)

These tools use a session layer that tracks simulators with custom session IDs:

📋 list-simulator-sessions - List all active simulator sessions
➕ create-simulator-session - Create a new simulator session
❌ terminate-simulator-session - Terminate a session (shuts down simulator and cleans up)
🔄 create-and-boot-simulator - Create a new simulator session and boot it
▶️ boot-simulator - Boot a simulator for an existing session
⏹️ shutdown-simulator - Shutdown a simulator for an existing session

Use this approach when: You need to track simulator metadata, reference simulators by custom IDs, or use the more advanced management features.

📲 Application Management

📥 install-app - Install an application on a simulator
🚀 launch-app - Launch an application on a simulator
🛑 terminate-app - Terminate a running application on a simulator

🖱️ Interaction Tools

📷 take-screenshot - Take a screenshot of the simulator screen
👆 tap-coordinate - Perform a tap at the specified coordinates

🤖 Example Usage with Claude Desktop

Configure Claude Desktop to use this server as an MCP tool:
- Open Claude Desktop
- Go to Settings > Advanced
- Add the following configuration to the "MCP Servers" section:
```
{
  "mcpServers": {
    "simulator": {
      "command": "node",
      "args": [
        "/path/to/your/mcp-server-ios-simulator/dist/index.js"
      ]
    }
  }
}
```
- Replace /path/to/your with the actual path to where you've installed this repository
- Save the settings and restart Claude Desktop
Use the provided tools to control iOS simulators directly from Claude Desktop:
Direct UDID Approach (Recommended):
1. First, ask Claude to list available simulators:
  "Show me all available iOS simulators"
2. Then use the UDID to boot a specific simulator:
  "Boot the iOS simulator with UDID 5272EA61-5796-4372-86FE-3B33831D5CC1"
3. When finished, shut it down using the same UDID:
  "Shut down the simulator with UDID 5272EA61-5796-4372-86FE-3B33831D5CC1"
The direct UDID approach is simpler and more reliable for most use cases.
Session-Based Approach (Advanced): Only use this approach if you need the advanced features of session tracking:
```
"Create a new simulator session for iPhone 16 Pro with iOS 18.2"
"Boot the simulator for session abc-123"
"Take a screenshot of the simulator for session abc-123"
"Terminate the simulator session abc-123"
```

👨‍💻 Development

📁 Project Structure

src/
├── simulator/       # Simulator management layer
├── mcp/             # MCP protocol implementation
├── bridge/          # Bridge component
├── utils/           # Utility functions including logger
├── config.ts        # Configuration handling
└── index.ts         # Entry point

🔨 Building the Project

# Install development dependencies
npm install

# Run TypeScript compiler
npm run build

📜 License

This project is licensed under the MIT License - see the LICENSE file for details.

🙏 Acknowledgments

📱 appium-ios-simulator for providing the iOS simulator interaction capabilities
🔌 Model Context Protocol for the protocol specification and TypeScript SDK

Available Tools

12 tools

boot-simulator-by-udidD

ParametersJSON Schema

Name	Required	Description	Default
`udid`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

create-simulator-sessionD

ParametersJSON Schema

Name	Required	Description	Default
`autoboot`	No
`deviceName`	No
`platformVersion`	No
`timeout`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

install-appD

ParametersJSON Schema

Name	Required	Description	Default
`appPath`	Yes
`sessionId`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

launch-appD

ParametersJSON Schema

Name	Required	Description	Default
`bundleId`	Yes
`sessionId`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list-available-simulatorsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list-booted-simulatorsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list-simulator-sessionsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

shutdown-simulatorD

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

shutdown-simulator-by-udidD

ParametersJSON Schema

Name	Required	Description	Default
`udid`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

tapD

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes
`x`	Yes
`y`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

terminate-appD

ParametersJSON Schema

Name	Required	Description	Default
`bundleId`	Yes
`sessionId`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

terminate-simulator-sessionD

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Install Server

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

TDQS

C2.2/5.0

Disambiguation5/5

Every tool has a clearly distinct purpose targeting specific simulator operations like booting, listing, installing apps, launching, tapping, and terminating. There is no ambiguity between tools - each handles a unique action on a specific resource (simulator, app, or session).

Naming Consistency5/5

All tools follow a consistent verb_noun or verb_noun_by_udid pattern with hyphen-separated lowercase words. The naming is perfectly predictable throughout the set, making it easy to understand each tool's function at a glance.

Tool Count5/5

With 12 tools, this server provides comprehensive coverage for iOS simulator management. The count is well-scoped for the domain, offering essential operations without being overwhelming or insufficient for typical automation workflows.

Completeness5/5

The toolset provides complete lifecycle coverage for iOS simulator operations: discovery (list-available/list-booted), control (boot/shutdown), app management (install/launch/terminate), session handling (create/terminate), and interaction (tap). No obvious gaps exist for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

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
l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

iOS Automation MCP Server
App Automation Testing & QA Tools Developer Tools
iHackSubhodip
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI assistants to interact with iOS simulators, perform accessibility testing, manage apps, and automate complex iOS workflows.
Updated a year ago (2025-07-26 12:41 UTC)
32
Apache 2.0
Simulator MCP
Developer Tools Testing & QA Tools App Automation
992429169
F
license
Not graded
quality
D
maintenance
Enables AI to control iOS simulators through the MCP protocol. Supports device management, UI automation, and network interception including screenshot capture, text input, and HTTP request mocking.
Updated 5 months ago (2026-04-14 07:53 UTC)
-
simctl-mcp
Developer Tools Virtualization Testing & QA Tools
ambar
A
license
B
quality
D
maintenance
A Model Context Protocol server implementation for iOS Simulator control, providing tools for device management, app operations, permissions, system features, and certificate handling.
Updated a year ago (2025-08-22 05:31 UTC)
29
20
20
MIT
ios-sim-mcp
Testing & QA Tools Developer Tools
artmamedov
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server for iOS Simulator automation. Enables AI assistants to visually interact with iOS apps running in the simulator.
Updated 8 months ago (2026-01-18 22:55 UTC)
41
1
MIT

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/atom2ueki/mcp-server-ios-simulator'

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