Xcode関連の操作ツールを提供するMCP（Model Context Protocol）サーバー。Claude DesktopなどのMCPクライアントからXcodeプロジェクトを簡単に操作できます。このサーバーは、Xcodeプロジェクト管理、ビルド、テスト、アーカイブ、コード署名、そして関連するiOS開発ツールのための様々なユーティリティを提供します。
Xcodeプロジェクト情報の取得とスキームの一覧表示
クリーンなカスタム出力オプションを備えた強化されたビルド機能
きめ細かな制御による包括的なテスト実行
アプリのアーカイブと配布用IPAエクスポート
コード署名とプロビジョニングプロファイル管理
Swift パッケージ マネージャーの統合
simctl による iOS シミュレータの管理
新機能: 自動 Xcode インストール検出と改善されたデバイス管理によるリアルデバイス アプリの展開と起動
自動再試行によるアプリのインストール失敗のインテリジェントな処理
デバイスとXcode情報をスマートにキャッシュしてパフォーマンスを向上
Related MCP server: sl-test
npm install @devyhan/xcode-mcpClaude Desktop の設定ファイルを開きます:
# macOS
open ~/Library/Application\ Support/Claude/claude_desktop_config.json次の構成を追加または変更します。
{
"mcpServers": {
"xcode-mcp": {
"command": "npx",
"args": [
"@devyhan/xcode-mcp",
"-y"
]
}
}
}Claude Desktop を再起動します。
ターゲット、構成、スキームなど、Xcode プロジェクトまたはワークスペースに関する詳細情報を取得します。
パラメータ:
projectPath (必須): Xcode プロジェクト (.xcodeproj) またはワークスペース (.xcworkspace) へのパス
例：
Project path: /Users/username/Projects/MyApp/MyApp.xcodeprojサンプル出力:
{
"project": {
"name": "MyApp",
"targets": ["MyApp", "MyAppTests", "MyAppUITests"],
"configurations": ["Debug", "Release"],
"schemes": ["MyApp"]
}
}Xcode プロジェクトまたはワークスペースで使用可能なすべてのスキーム、ターゲット、および構成の包括的なリストを提供します。
パラメータ:
projectPath (必須): Xcode プロジェクト (.xcodeproj) またはワークスペース (.xcworkspace) へのパス
例：
Project path: /Users/username/Projects/MyApp/MyApp.xcodeprojサンプル出力:
Information about project "MyApp":
Targets:
MyApp
MyAppTests
MyAppUITests
Build Configurations:
Debug
Release
Schemes:
MyApp
MyAppTests拡張オプションを使用してXcodeプロジェクトまたはワークスペースをビルドします。ワークスペースとプロジェクトの両方のビルド、クリーンビルド、カスタム出力ディレクトリをサポートします。
パラメータ:
projectPath (必須): Xcode プロジェクト (.xcodeproj) またはワークスペース (.xcworkspace) へのパス
scheme （必須）: 構築するスキーム
configuration （オプション）：ビルド構成（例：デバッグ、リリース）
destination （オプション）：ビルド先（例： 'platform=iOS Simulator,name=iPhone 14'）
extraArgs (オプション): 追加の xcodebuild 引数を文字列の配列として指定します。
outputDir (オプション): カスタムビルド出力ディレクトリ (SYMROOT)
clean (オプション): クリーンビルドを実行するかどうか (デフォルト: false)
例：
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: MyAppScheme
Configuration: Debug
Destination: platform=iOS Simulator,name=iPhone 14
Clean: true
OutputDir: /Users/username/Desktop/build生成されたコマンド:
xcodebuild -project "/Users/username/Projects/MyApp/MyApp.xcodeproj" -scheme "MyAppScheme" clean build -configuration "Debug" -destination "platform=iOS Simulator,name=iPhone 14" SYMROOT="/Users/username/Desktop/build"豊富なオプションを使用して、Xcode プロジェクトまたはワークスペースのテストを実行します。特定のテスト、テストプラン、さまざまなテストモードの実行など、テスト実行をきめ細かく制御できます。
パラメータ:
projectPath (必須): Xcode プロジェクト (.xcodeproj) またはワークスペース (.xcworkspace) へのパス
scheme (必須): テストするスキーム
destination （必須）：テストの宛先（例：'platform=iOS Simulator,name=iPhone 14'）
testPlan (オプション): 使用するテストプランの名前
onlyTesting (オプション): 実行する特定のテスト識別子の配列
skipTesting (オプション): スキップするテスト識別子の配列
resultBundlePath (オプション): テスト結果バンドルを保存するパス
buildForTesting (オプション): テストを実行せずにテストのみを目的としてビルドする
testWithoutBuilding (オプション): ビルドせずにテストを実行する
例：
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: MyAppScheme
Destination: platform=iOS Simulator,name=iPhone 14
OnlyTesting: ["MyAppTests/LoginTests"]
ResultBundlePath: /Users/username/Desktop/TestResults生成されたコマンド:
xcodebuild -project "/Users/username/Projects/MyApp/MyApp.xcodeproj" -scheme "MyAppScheme" -destination "platform=iOS Simulator,name=iPhone 14" test -only-testing:"MyAppTests/LoginTests" -resultBundlePath "/Users/username/Desktop/TestResults"Xcodeプロジェクトのアーカイブ（.xcarchive）を作成し、オプションで配布用のIPAファイルにエクスポートします。エクスポートオプションのplistを通じて、App Store、アドホック、エンタープライズ向けの配布方法をサポートします。
パラメータ:
projectPath (必須): Xcode プロジェクト (.xcodeproj) またはワークスペース (.xcworkspace) へのパス
scheme （必須）: アーカイブするスキーム
configuration （オプション）：ビルド構成（例：リリース）
archivePath (必須): .xcarchive ファイルを保存するパス
exportPath (オプション): アーカイブをエクスポートするパス (例: IPA ファイル)
exportOptionsPlist (オプション): exportOptions.plist ファイルへのパス
例：
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: MyAppScheme
Configuration: Release
ArchivePath: /Users/username/Desktop/MyApp.xcarchive
ExportPath: /Users/username/Desktop/Export
ExportOptionsPlist: /Users/username/Projects/MyApp/exportOptions.plist生成されたコマンド:
# Archive command
xcodebuild -project "/Users/username/Projects/MyApp/MyApp.xcodeproj" -scheme "MyAppScheme" -configuration "Release" archive -archivePath "/Users/username/Desktop/MyApp.xcarchive"
# Export command (if exportPath and exportOptionsPlist are provided)
xcodebuild -exportArchive -archivePath "/Users/username/Desktop/MyApp.xcarchive" -exportPath "/Users/username/Desktop/Export" -exportOptionsPlist "/Users/username/Projects/MyApp/exportOptions.plist"Xcodeプロジェクトの包括的なコード署名およびプロビジョニングプロファイル情報を取得します。システムにインストールされているコード署名ID、プロジェクトのコード署名設定、およびプロビジョニングプロファイルを表示します。
パラメータ:
projectPath (必須): Xcode プロジェクト (.xcodeproj) またはワークスペース (.xcworkspace) へのパス
target （オプション）: 特定のターゲット名
例：
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Target: MyAppTargetサンプル出力:
코드 서명 인증서 목록:
1) 01AB2345CD6789EF0123456789ABCDEF01234567 "Apple Development: John Doe (ABC12DEF34)"
2) 9876543210FEDCBA98765432109876543210FEDC "Apple Distribution: Example Corp (XYZ12ABC3)"
프로젝트 코드 서명 설정:
CODE_SIGN_IDENTITY = Apple Development
CODE_SIGN_STYLE = Automatic
DEVELOPMENT_TEAM = ABC123DEF4
PROVISIONING_PROFILE_SPECIFIER =
설치된 프로비저닝 프로파일:
-rw-r--r-- 1 username staff 12345 Feb 1 12:34 01234567-89ab-cdef-0123-456789abcdef.mobileprovision
-rw-r--r-- 1 username staff 23456 Mar 15 09:12 fedcba98-7654-3210-fedc-ba9876543210.mobileprovisionSwift パッケージを管理するための Swift Package Manager (SPM) 機能へのアクセスを提供します。init、update、resolve、reset、clean などの一般的な SPM コマンドをサポートします。
パラメータ:
command (必須): 実行する SPM コマンド ("init"、"update"、"resolve"、"reset"、"clean")
packageDir (必須): Swift パッケージのディレクトリ パス
extraArgs (オプション): 追加の SPM 引数 (文字列の配列)
例：
Command: update
PackageDir: /Users/username/Projects/MySwiftPackage
ExtraArgs: ["--enable-pubgrub-resolver"]生成されたコマンド:
cd "/Users/username/Projects/MySwiftPackage" && swift package update --enable-pubgrub-resolverサンプル出力:
Resolving dependencies...
Fetching https://github.com/example/example-package.git
Checking out https://github.com/example/example-package.git at 1.2.3simctlコマンドラインツールを介してiOSシミュレータの管理機能へのアクセスを提供します。アプリの一覧表示、作成、起動、インストール、シミュレータデバイスの管理をサポートします。
パラメータ:
command （必須）：SimCtlコマンド（「list」、「create」、「boot」、「shutdown」、「erase」、「install」、「launch」、「delete」）
extraArgs (オプション): 追加の simctl 引数を文字列の配列として指定します。
例：
Command: list
ExtraArgs: ["devices", "--json"]生成されたコマンド:
xcrun simctl list devices --jsonサンプル出力（省略） :
{
"devices": {
"com.apple.CoreSimulator.SimRuntime.iOS-17-0": [
{
"name": "iPhone 14",
"udid": "12345678-1234-1234-1234-123456789ABC",
"state": "Booted",
"isAvailable": true
}
]
}
}物理iOSデバイス上でアプリをビルド、インストール、実行します。デバイス名（韓国語名を含む）またはUUIDによるデバイス選択、環境変数、ログストリーミングをサポートします。また、bundleIdの直接指定、ビルドスキップオプション、追加の起動引数もサポートします。
パラメータ:
projectPath (必須): Xcode プロジェクト (.xcodeproj) またはワークスペース (.xcworkspace) へのパス
scheme （必須）: ビルドして実行するスキーム
device （必須）: デバイス識別子または名前（韓国語名をサポート）
configuration （オプション）：ビルド構成（例：デバッグ、リリース）
streamLogs (オプション): 起動後にデバイスログをストリーミングするかどうか
startStopped (オプション): デバッガー接続のために一時停止状態でアプリを起動するかどうか
environmentVars (オプション): アプリに渡す環境変数 (key1=value1、key2=value2 形式)
xcodePath (オプション): Xcode アプリケーション パス (デフォルト: "/Applications/Xcode-16.2.0.app")
listDevices (オプション): 実行前に検出されたすべてのデバイスとそのIDを表示します。
skipBuild （オプション）：すでにインストールされているアプリのビルドとインストールの手順をスキップします
extraLaunchArgs (オプション): devicectl launch コマンドに渡す追加の引数
directBundleId (オプション): プロジェクトから抽出するのではなく、バンドルIDを直接指定します。
例：
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: MyAppScheme
Device: "Your-iPhone"
Configuration: Debug
StreamLogs: true
EnvironmentVars: "DEBUG_MODE=1,API_URL=https://test-api.example.com"プロセス：
このツールは指定されたデバイスのXcode UDIDとCoreDevice UUIDの両方を識別します。
アプリのビルドとインストールにはXcode UDIDを使用します
devicectlでアプリを起動するためにCoreDevice UUIDを使用する
アプリのバンドル識別子を取得します
要求に応じて、デバイスのログをストリーミングします
v0.4.0の主な改善点:
プロジェクトを必要とせずにbundleIdを直接指定する機能
すでにインストールされているアプリのビルドとインストールの手順をスキップする
追加のdevicectl起動コマンド引数のサポート
デバイスモデルとOSバージョン情報の表示の改善
devicectlコマンドのパス処理とログ記録の改善
サンプル出力:
// Standard output with build and install
앱 실행 결과:
Launched application with com.example.myapp bundle identifier.
로그 스트리밍이 시작되었습니다. 로그는 터미널에서 확인할 수 있습니다.
// Direct bundle ID usage with skip build
기기 모델: iPhone14,7
기기 OS 버전: 17.0
사용자 지정 번들 ID 사용: com.example.myapp
빌드 및 설치 과정 건너뛰기
앱 실행 결과:
Launched application with com.example.myapp bundle identifier.以下は、Claude のような LLM にこれらのツールを順番に使用するように指示する方法の例です。
クロードへのユーザープロンプト:
I need to inspect my Xcode project, run some tests, and then archive it for distribution.
1. First, use the xcode-list-schemes tool to get all available schemes for my project at /Users/username/Projects/MyApp/MyApp.xcodeproj
2. After you see the schemes, run tests for the first available scheme on the iPhone 14 simulator.
3. Then archive the app for distribution using the Release configuration.予想されるワークフロー:
Claude はxcode-list-schemesツールを実行してすべてのスキームを取得します。
Project path: /Users/username/Projects/MyApp/MyApp.xcodeprojClaude は、識別されたスキームを使用してxcode-testツールを実行します。
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: [First scheme from output]
Destination: platform=iOS Simulator,name=iPhone 14次に、Claude はxcode-archiveツールを使用してアーカイブを作成します。
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: [First scheme from output]
Configuration: Release
ArchivePath: /Users/username/Desktop/MyApp.xcarchiveこのワークフローは、1 つのツールからの出力を使用して別のツールのパラメータに通知し、複数のツールを連結する方法を示します。
クロードへのユーザープロンプト:
I need to test my app on a real device:
1. Get the list of available devices (including connected physical devices)
2. Run my app on my connected iPhone 予想されるワークフロー:
クロードはまずデバイスのリストを取得します。
listDevices: trueClaude は物理デバイスを識別し、その上でアプリを実行します。
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: MyApp
Device: "Your iPhone" (or the device UUID)
StreamLogs: true再構築せずにすぐに再起動するには:
Device: "Your iPhone"
DirectBundleId: "com.example.myapp"
SkipBuild: trueこのツールはXcode関連のコマンドを実行する可能性があり、セキュリティリスクを伴います。ご注意ください。
信頼できる Xcode プロジェクトでのみ使用してください。
不明なソースからのプロジェクトには注意してください。
ビルドパラメータに機密情報を含めないでください。
Node.js 16以上
npm 6以上
Xcode 14以上（すべての機能）
Xcode 16以上（ devicectlおよび実デバイス機能に必要）
# Clone the repository
git clone https://github.com/devyhan/xcode-mcp.git
cd xcode-mcp
# Install dependencies
npm install
# Run in development mode
npm run dev
# Build
npm run build
# Test
npm testマサチューセッツ工科大学
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Xcode 프로젝트 또는 워크스페이스 경로 | |
| scheme | Yes | 빌드 및 실행할 스킴 | |
| device | Yes | 기기 식별자 또는 이름 (한글 이름 지원) | |
| configuration | No | 빌드 구성 (Debug/Release) | |
| streamLogs | No | 앱 실행 후 로그 스트리밍 여부 | |
| startStopped | No | 디버거 연결을 위한 일시 중지 상태로 시작 | |
| environmentVars | No | 앱에 전달할 환경 변수 (key1=value1,key2=value2 형식) | |
| xcodePath | No | Xcode 애플리케이션 경로 | |
| listDevices | No | 실행 전 감지된 모든 디바이스 목록 표시 | |
| skipBuild | No | 이미 설치된 앱을 재실행할 때 빌드 및 설치 건너뛰기 | |
| extraLaunchArgs | No | devicectl launch 명령어에 전달할 추가 인자 | |
| directBundleId | No | 직접 지정할 번들 ID (프로젝트에서 추출하지 않음) |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | SimCtl 명령어 | |
| extraArgs | No | 추가 simctl 인자들 |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | SPM 명령어 (init, update, resolve, reset, clean) | |
| packageDir | Yes | Swift Package 디렉토리 경로 | |
| extraArgs | No | 추가 SPM 인자들 |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Xcode 프로젝트 또는 워크스페이스 경로 | |
| scheme | Yes | 아카이브할 스킴 | |
| configuration | No | 빌드 구성 (예: Release) | |
| archivePath | Yes | 아카이브 파일(.xcarchive) 저장 경로 | |
| exportPath | No | 익스포트 경로 (IPA 파일 등) | |
| exportOptionsPlist | No | 익스포트 옵션 plist 파일 경로 |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Xcode 프로젝트 또는 워크스페이스 경로 | |
| scheme | Yes | 빌드할 스킴 | |
| configuration | No | 빌드 구성 (예: Debug, Release) | |
| destination | No | 빌드 대상 (예: 'platform=iOS Simulator,name=iPhone 14') | |
| extraArgs | No | 추가 xcodebuild 인자들 | |
| outputDir | No | 빌드 결과물 저장 경로 (SYMROOT) | |
| clean | No | 빌드 전 clean 실행 여부 |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Xcode 프로젝트 또는 워크스페이스 경로 | |
| target | No | 특정 타겟 이름 (선택사항) |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Xcode 프로젝트 또는 워크스페이스 경로 |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Xcode 프로젝트 또는 워크스페이스 경로 |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Xcode 프로젝트 또는 워크스페이스 경로 | |
| scheme | Yes | 테스트할 스킴 | |
| destination | Yes | 테스트 대상 (예: 'platform=iOS Simulator,name=iPhone 14') | |
| testPlan | No | 사용할 테스트 플랜 이름 | |
| onlyTesting | No | 실행할 특정 테스트 식별자들 (예: ['ModuleTests/ClassTests/testMethod']) | |
| skipTesting | No | 건너뛸 테스트 식별자들 | |
| resultBundlePath | No | 테스트 결과 번들 저장 경로 | |
| buildForTesting | No | 테스트용 빌드만 수행할지 여부 | |
| testWithoutBuilding | No | 빌드 없이 테스트만 수행할지 여부 |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
run-on-devicesimctl-managerswift-package-managerxcode-archivexcode-buildxcode-codesign-infoxcode-list-schemesxcode-project-infoxcode-testMost tools have clearly distinct purposes targeting different Xcode workflows (building, testing, archiving, etc.), though 'simctl-manager' and 'run-on-device' could potentially overlap in device-related operations. The lack of descriptions makes it harder to fully assess boundaries, but the naming suggests reasonable separation.
There's a mixed naming convention: most tools use a consistent 'xcode-' prefix with snake_case (e.g., 'xcode-build'), but 'simctl-manager', 'swift-package-manager', and 'run-on-device' deviate from this pattern. This inconsistency reduces predictability, though the names remain generally readable.
With 9 tools, the count is well-scoped for an Xcode development server, covering key operations like building, testing, and project management. Each tool appears to serve a distinct function, avoiding both bloat and thin coverage for the domain.
The tools cover core development workflows (build, test, archive, etc.) but lack descriptions make it hard to assess gaps fully. Based on naming, there might be missing operations like code editing, debugging, or version control integration, which are common in Xcode environments, suggesting moderate incompleteness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Appcircle mobile CI/CD platform.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Build, run, and inspect iOS apps in disposable hosted Simulators from cloud coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/devyhan/xcode-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
