Xcode 관련 작업을 위한 도구를 제공하는 MCP(Model Context Protocol) 서버로, Claude Desktop과 같은 MCP 클라이언트에서 Xcode 프로젝트 작업을 더욱 쉽게 수행할 수 있도록 합니다. 이 서버는 Xcode 프로젝트 관리, 빌드, 테스트, 보관, 코드 서명 및 관련 iOS 개발 도구를 위한 다양한 유틸리티를 제공합니다.
Xcode 프로젝트 정보 검색 및 스키마 목록
깔끔하고 사용자 정의 가능한 출력 옵션을 통해 향상된 빌드 기능
세부적인 제어를 통한 포괄적인 테스트 실행
배포를 위한 앱 보관 및 IPA 내보내기
코드 서명 및 프로비저닝 프로필 관리
Swift 패키지 관리자 통합
simctl을 통한 iOS 시뮬레이터 관리
새로운 기능: 자동 Xcode 설치 감지 및 향상된 장치 관리를 통한 실제 장치 앱 배포 및 실행
자동 재시도로 앱 설치 실패를 지능적으로 처리합니다.
더 나은 성능을 위한 장치 및 Xcode 정보의 스마트 캐싱
Related MCP server: sl-test
지엑스피1
Claude 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 (선택 사항): 빌드 대상(예: '플랫폼=iOS 시뮬레이터, 이름=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 (필수): 테스트 대상(예: '플랫폼=iOS 시뮬레이터, 이름=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 패키지 관리자(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 실행 명령에 전달할 추가 인수
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이 워크플로는 한 도구의 출력을 사용하여 다른 도구의 매개변수를 알려주고 여러 도구를 연결하는 방법을 보여줍니다.
클로드에게 사용자 프롬프트:
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 예상 작업 흐름:
Claude는 먼저 장치 목록을 가져옵니다.
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 testMIT
| 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.
run-on-devicesimctl-managerswift-package-managerxcode-archivexcode-buildxcode-codesign-infoxcode-list-schemesxcode-project-infoxcode-testScored across 9 tools
Most 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.
MCP server for Appcircle mobile CI/CD platform.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for Studex tools, notifications, and profile integrations
A Model Context Protocol server for Wix AI tools
