Skip to main content
Glama
deenesjakoruzh
atom2ueki

MCP Server for iOS Simulator

by atom2ueki
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

📱 iOSシミュレーター用MCPサーバー

appium-ios-simulatorをベースに構築され、MCP TypeScript SDKを利用した、iOSシミュレーター用のModel Context Protocol（MCP）実装サーバーです。

📋 概要

本プロジェクトは、iOSシミュレーターとModel Context Protocolの間のブリッジを提供し、iOSシミュレーターインスタンスとの標準化された通信を可能にします。MCPプロトコルを活用することで、異なる環境間で一貫したインターフェースを維持しながら、iOSシミュレーターをプログラムで制御できます。サーバーはトランスポートメカニズムとしてstdioを使用しており、Claude Desktopやその他のMCP互換クライアントとの統合に最適です。

Related MCP server: Simulator MCP

🎬 デモ

iOS Simulator Demo

Claude AI Desktopを使用してiOSシミュレーターを起動するデモ

🏗️ アーキテクチャ

サーバーは主に3つのコンポーネントで構成されています：

  1. 🔄 シミュレーター管理レイヤー - iOSシミュレーターのライフサイクルと対話を処理

  2. 🔌 MCPプロトコル実装 - TypeScript SDKとstdioトランスポートを使用したModel Context Protocolの実装

  3. 📊 ロガーコンポーネント - stdioトランスポートを妨げないファイルベースのログ出力機能

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

✨ 機能

  • 🚀 iOSシミュレーターインスタンスの起動、停止、管理

  • 🔌 シミュレーターのブートおよびシャットダウン

  • 📲 シミュレーターへのアプリインストールおよび起動

  • 📸 シミュレーター画面のスクリーンショット撮影

  • 👆 指定座標のタップ操作

  • 🔄 複数のシミュレーターセッションの同時実行サポート

  • 📝 コンソール出力を行わない包括的なファイルベースのログ出力

  • 🛡️ エラー耐性のある動作

📋 前提条件

  • 🟢 Node.js (v16以上)

  • 🍎 macOS (iOSシミュレーターに必須)

  • 🛠️ Xcode (iOSシミュレーターがインストールされていること)

  • 📜 TypeScript 4.5+

🔧 インストール

Smithery経由でのインストール

Smithery経由でClaude Desktop用のiOSシミュレーター制御サーバーを自動インストールするには：

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

手動インストール

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

# Install dependencies
npm install

🐳 Docker

Glama MCPディレクトリやその他のコンテナホスト向けにパッケージ化できるよう、Dockerfileが提供されています。

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

注意: iOSシミュレーターはmacOS上でのみ動作するため、LinuxコンテナはMCPプロセスをホストしてstdioで応答することは可能ですが、実際のシミュレーターを駆動することはできません。このコンテナは、移植性の確認や、macOSホストにブリッジするリモートMCP環境を目的としています。

⚙️ 設定

設定はsrc/config.tsファイルを通じて行います：

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),
  }
};

環境変数を設定することで、これらの設定をカスタマイズできます：

SIMULATOR_DEFAULT_DEVICE=iPhone 16
SIMULATOR_DEFAULT_OS=18.2
SIMULATOR_TIMEOUT=30000

🚀 使用方法

🔨 サーバーのビルドと起動

# Build the project
npm run build

# Start the server
npm start

🧰 MCPツール

本サーバーは、iOSシミュレーターを制御するために2つの異なるアプローチを提供します：

📱 直接シミュレーター管理（推奨）

これらのツールはシミュレーターのUDIDを直接操作するため、セッションを維持する必要はありません：

  • 📋 list-available-simulators - 利用可能なすべてのシミュレーターをUDID付きで一覧表示

  • ▶️ boot-simulator-by-udid - UDIDを使用してシミュレーターを直接起動

  • ⏹️ shutdown-simulator-by-udid - UDIDを使用してシミュレーターを直接シャットダウン

  • 📊 list-booted-simulators - 現在起動中のすべてのシミュレーターを一覧表示

このアプローチを使用する場合: シミュレーターを直接起動、使用、シャットダウンしたい場合に適しています。

📱 セッションベースの管理（高度）

これらのツールは、カスタムセッションIDでシミュレーターを追跡するセッションレイヤーを使用します：

  • 📋 list-simulator-sessions - アクティブなすべてのシミュレーターセッションを一覧表示

  • ➕ create-simulator-session - 新しいシミュレーターセッションを作成

  • ❌ terminate-simulator-session - セッションを終了（シミュレーターのシャットダウンとクリーンアップを実行）

  • 🔄 create-and-boot-simulator - 新しいシミュレーターセッションを作成して起動

  • ▶️ boot-simulator - 既存セッションのシミュレーターを起動

  • ⏹️ shutdown-simulator - 既存セッションのシミュレーターをシャットダウン

このアプローチを使用する場合: シミュレーターのメタデータを追跡したり、カスタムIDでシミュレーターを参照したり、より高度な管理機能を使用する必要がある場合に適しています。

📲 アプリケーション管理

  • 📥 install-app - シミュレーターにアプリケーションをインストール

  • 🚀 launch-app - シミュレーターでアプリケーションを起動

  • 🛑 terminate-app - シミュレーターで実行中のアプリケーションを終了

🖱️ インタラクションツール

  • 📷 take-screenshot - シミュレーター画面のスクリーンショットを撮影

  • 👆 tap-coordinate - 指定された座標をタップ

🤖 Claude Desktopでの使用例

  1. Claude DesktopがこのサーバーをMCPツールとして使用するように設定します：

    • Claude Desktopを開く

    • 設定 > 詳細設定 に移動

    • 「MCP Servers」セクションに以下の設定を追加：

    {
  "mcpServers": {
    "simulator": {
      "command": "node",
      "args": [
        "/path/to/your/mcp-server-ios-simulator/dist/index.js"
      ]
    }
  }
}

    • /path/to/your を、このリポジトリをインストールした実際のパスに置き換えてください

    • 設定を保存し、Claude Desktopを再起動します

  2. 提供されたツールを使用して、Claude Desktopから直接iOSシミュレーターを制御します：

    直接UDIDアプローチ（推奨）:

    1. まず、Claudeに利用可能なシミュレーターを一覧表示させます：

      "Show me all available iOS simulators"

    2. 次に、UDIDを使用して特定のシミュレーターを起動します：

      "Boot the iOS simulator with UDID 5272EA61-5796-4372-86FE-3B33831D5CC1"

    3. 終了したら、同じUDIDを使用してシャットダウンします：

      "Shut down the simulator with UDID 5272EA61-5796-4372-86FE-3B33831D5CC1"

    直接UDIDアプローチは、ほとんどのユースケースにおいてよりシンプルで信頼性が高いです。

    セッションベースのアプローチ（高度）: セッション追跡の高度な機能が必要な場合にのみ、このアプローチを使用してください：

    "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"

👨💻 開発

📁 プロジェクト構造

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

🔨 プロジェクトのビルド

# Install development dependencies
npm install

# Run TypeScript compiler
npm run build

📜 ライセンス

本プロジェクトはMITライセンスの下でライセンスされています。詳細はLICENSEファイルを参照してください。

🙏 謝辞

Available Tools

12 tools
boot-simulator-by-udidD
ParametersJSON Schema
NameRequiredDescriptionDefault
udidYes

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
NameRequiredDescriptionDefault
autobootNo
deviceNameNo
platformVersionNo
timeoutNo

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
NameRequiredDescriptionDefault
appPathYes
sessionIdYes

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
NameRequiredDescriptionDefault
bundleIdYes
sessionIdYes

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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
sessionIdYes

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
NameRequiredDescriptionDefault
udidYes

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
NameRequiredDescriptionDefault
sessionIdYes
xYes
yYes

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
NameRequiredDescriptionDefault
bundleIdYes
sessionIdYes

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
NameRequiredDescriptionDefault
sessionIdYes

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 12 tool updatesv1.0.0
    • First observedboot-simulator-by-udid
    • First observedcreate-simulator-session
    • First observedinstall-app
    • First observedlaunch-app
    • First observedlist-available-simulators
    • First observedlist-booted-simulators
    • First observedlist-simulator-sessions
    • First observedshutdown-simulator
    • First observedshutdown-simulator-by-udid
    • First observedtap
    • First observedterminate-app
    • First observedterminate-simulator-session
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.2/5.0

Scored across 12 tools

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

Related MCP Connectors

Related MCP Servers