Un servidor MCP (Protocolo de Contexto de Modelo) que proporciona herramientas para operaciones relacionadas con Xcode, lo que facilita el trabajo con proyectos Xcode desde clientes MCP como Claude Desktop. El servidor ofrece diversas utilidades para la gestión de proyectos Xcode, la creación, las pruebas, el archivado, la firma de código y otras herramientas de desarrollo para iOS.
Recuperación de información del proyecto Xcode y listado de esquemas
Capacidades de compilación mejoradas con opciones de salida limpias y personalizadas
Ejecución de pruebas integral con control granular
Archivado de aplicaciones y exportación de IPA para distribución
Gestión de perfiles de aprovisionamiento y firma de código
Integración de Swift Package Manager
Gestión del simulador de iOS mediante simctl
NUEVO: Implementación y lanzamiento de aplicaciones en dispositivos reales con detección automática de instalación de Xcode y administración mejorada de dispositivos
Manejo inteligente de errores de instalación de aplicaciones con reintento automático
Almacenamiento en caché inteligente de información del dispositivo y de Xcode para un mejor rendimiento
Related MCP server: sl-test
npm install @devyhan/xcode-mcpAbra el archivo de configuración de Claude Desktop:
# macOS
open ~/Library/Application\ Support/Claude/claude_desktop_config.jsonAgregue o modifique la siguiente configuración:
{
"mcpServers": {
"xcode-mcp": {
"command": "npx",
"args": [
"@devyhan/xcode-mcp",
"-y"
]
}
}
}Reinicie Claude Desktop.
Recupera información detallada sobre un proyecto o espacio de trabajo de Xcode, incluidos objetivos, configuraciones y esquemas.
Parámetros :
projectPath (obligatorio): ruta al proyecto Xcode (.xcodeproj) o al espacio de trabajo (.xcworkspace)
Ejemplo :
Project path: /Users/username/Projects/MyApp/MyApp.xcodeprojSalida de muestra :
{
"project": {
"name": "MyApp",
"targets": ["MyApp", "MyAppTests", "MyAppUITests"],
"configurations": ["Debug", "Release"],
"schemes": ["MyApp"]
}
}Proporciona una lista completa de todos los esquemas, objetivos y configuraciones disponibles en un proyecto o espacio de trabajo de Xcode.
Parámetros :
projectPath (obligatorio): ruta al proyecto Xcode (.xcodeproj) o al espacio de trabajo (.xcworkspace)
Ejemplo :
Project path: /Users/username/Projects/MyApp/MyApp.xcodeprojSalida de muestra :
Information about project "MyApp":
Targets:
MyApp
MyAppTests
MyAppUITests
Build Configurations:
Debug
Release
Schemes:
MyApp
MyAppTestsCrea un proyecto o espacio de trabajo de Xcode con opciones mejoradas. Admite compilaciones de proyectos y espacios de trabajo, compilaciones limpias y directorios de salida personalizados.
Parámetros :
projectPath (obligatorio): ruta al proyecto Xcode (.xcodeproj) o al espacio de trabajo (.xcworkspace)
scheme (obligatorio): El esquema para construir
configuration (opcional): Configuración de compilación (por ejemplo, Depuración, Versión)
destination (opcional): destino de compilación (por ejemplo, 'plataforma=iOS Simulator,nombre=iPhone 14')
extraArgs (opcional): argumentos adicionales de xcodebuild como una matriz de cadenas
outputDir (opcional): directorio de salida de compilación personalizado (SYMROOT)
clean (opcional): si se debe realizar una compilación limpia (predeterminado: falso)
Ejemplo :
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/buildComando generado :
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"Ejecuta pruebas para un proyecto o espacio de trabajo de Xcode con amplias opciones. Proporciona un control preciso sobre la ejecución de pruebas, incluyendo la ejecución de pruebas específicas, planes de prueba y diversos modos de prueba.
Parámetros :
projectPath (obligatorio): ruta al proyecto Xcode (.xcodeproj) o al espacio de trabajo (.xcworkspace)
scheme (obligatorio): El esquema a probar
destination (obligatorio): destino de la prueba (p. ej., 'plataforma=iOS Simulator,nombre=iPhone 14')
testPlan (opcional): Nombre del plan de prueba a utilizar
onlyTesting (opcional): Matriz de identificadores de prueba específicos para ejecutar
skipTesting (opcional): Matriz de identificadores de prueba para omitir
resultBundlePath (opcional): Ruta para guardar el paquete de resultados de la prueba
buildForTesting (opcional): compilar solo para probar sin ejecutar pruebas
testWithoutBuilding (opcional): ejecuta pruebas sin compilar
Ejemplo :
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: MyAppScheme
Destination: platform=iOS Simulator,name=iPhone 14
OnlyTesting: ["MyAppTests/LoginTests"]
ResultBundlePath: /Users/username/Desktop/TestResultsComando generado :
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"Crea un archivo (.xcarchive) de un proyecto de Xcode y, opcionalmente, lo exporta a un archivo IPA para su distribución. Compatible con los métodos de distribución de App Store, ad-hoc y empresariales mediante la opción de exportación plist.
Parámetros :
projectPath (obligatorio): ruta al proyecto Xcode (.xcodeproj) o al espacio de trabajo (.xcworkspace)
scheme (obligatorio): El esquema a archivar
configuration (opcional): Configuración de compilación (por ejemplo, versión)
archivePath (obligatorio): Ruta para guardar el archivo .xcarchive
exportPath (opcional): Ruta para exportar el archivo (por ejemplo, archivo IPA)
exportOptionsPlist (opcional): Ruta al archivo exportOptions.plist
Ejemplo :
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.plistComandos generados :
# 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"Recupera información completa sobre la firma de código y los perfiles de aprovisionamiento de un proyecto de Xcode. Muestra las identidades de firma de código instaladas, la configuración de firma de código del proyecto y los perfiles de aprovisionamiento en el sistema.
Parámetros :
projectPath (obligatorio): ruta al proyecto Xcode (.xcodeproj) o al espacio de trabajo (.xcworkspace)
target (opcional): nombre del objetivo específico
Ejemplo :
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Target: MyAppTargetSalida de muestra :
코드 서명 인증서 목록:
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.mobileprovisionProporciona acceso a la funcionalidad del Gestor de Paquetes Swift (SPM) para gestionar paquetes Swift. Admite comandos comunes de SPM como init, update, resolve, reset y clean.
Parámetros :
command (obligatorio): comando SPM a ejecutar ("init", "update", "resolve", "reset", "clean")
packageDir (obligatorio): Ruta del directorio del paquete Swift
extraArgs (opcional): argumentos SPM adicionales como una matriz de cadenas
Ejemplo :
Command: update
PackageDir: /Users/username/Projects/MySwiftPackage
ExtraArgs: ["--enable-pubgrub-resolver"]Comando generado :
cd "/Users/username/Projects/MySwiftPackage" && swift package update --enable-pubgrub-resolverSalida de muestra :
Resolving dependencies...
Fetching https://github.com/example/example-package.git
Checking out https://github.com/example/example-package.git at 1.2.3Proporciona acceso a las funciones de gestión del simulador de iOS mediante la herramienta de línea de comandos simctl . Permite listar, crear, iniciar, instalar aplicaciones y gestionar dispositivos del simulador.
Parámetros :
command (obligatorio): comando SimCtl ("lista", "crear", "arrancar", "apagar", "borrar", "instalar", "iniciar", "eliminar")
extraArgs (opcional): argumentos simctl adicionales como una matriz de cadenas
Ejemplo :
Command: list
ExtraArgs: ["devices", "--json"]Comando generado :
xcrun simctl list devices --jsonEjemplo de salida (abreviado) :
{
"devices": {
"com.apple.CoreSimulator.SimRuntime.iOS-17-0": [
{
"name": "iPhone 14",
"udid": "12345678-1234-1234-1234-123456789ABC",
"state": "Booted",
"isAvailable": true
}
]
}
}Crea, instala y ejecuta una aplicación en un dispositivo iOS físico. Admite el nombre del dispositivo (incluidos los nombres en coreano) o UUID para la selección del dispositivo, las variables de entorno y la transmisión de registros. Ahora con especificación directa de bundleId, opción para omitir la compilación y argumentos de lanzamiento adicionales .
Parámetros :
projectPath (obligatorio): ruta al proyecto Xcode (.xcodeproj) o al espacio de trabajo (.xcworkspace)
scheme (obligatorio): El esquema para construir y ejecutar
device (obligatorio): identificador o nombre del dispositivo (admite nombres coreanos)
configuration (opcional): Configuración de compilación (por ejemplo, Depuración, Versión)
streamLogs (opcional): si se deben transmitir los registros del dispositivo después del lanzamiento
startStopped (opcional): si se debe iniciar la aplicación en un estado de pausa para adjuntarla al depurador
environmentVars (opcional): Variables de entorno para pasar a la aplicación (formato clave1=valor1,clave2=valor2)
xcodePath (opcional): ruta de la aplicación Xcode (predeterminado: "/Applications/Xcode-16.2.0.app")
listDevices (opcional): muestra todos los dispositivos detectados con sus ID antes de ejecutarse
skipBuild (opcional): omite el paso de compilación e instalación para aplicaciones ya instaladas
extraLaunchArgs (opcional): argumentos adicionales para pasar al comando de lanzamiento devicectl
directBundleId (opcional): especifica directamente el ID del paquete en lugar de extraerlo del proyecto
Ejemplo :
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"Proceso :
La herramienta identifica tanto el UDID de Xcode como el UUID de CoreDevice para el dispositivo especificado
Utiliza el UDID de Xcode para crear e instalar la aplicación.
Utiliza el UUID de CoreDevice para iniciar la aplicación con devicectl
Recupera el identificador del paquete de la aplicación.
Si se solicita, transmite los registros del dispositivo.
Mejoras clave en la versión v0.4.0 :
Capacidad de especificar bundleId directamente sin necesidad de un proyecto
Omitir el paso de compilación e instalación para aplicaciones ya instaladas
Compatibilidad con argumentos adicionales del comando de lanzamiento devicectl
Mejor visualización de la información del modelo del dispositivo y de la versión del sistema operativo
Manejo de rutas y registro mejorados para comandos devicectl
Salida de muestra :
// 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.A continuación se muestra un ejemplo de cómo se podría incentivar a un LLM como Claude a utilizar estas herramientas en secuencia:
Mensaje de usuario a Claude:
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.Flujo de trabajo esperado:
Claude ejecutará la herramienta xcode-list-schemes para recuperar todos los esquemas:
Project path: /Users/username/Projects/MyApp/MyApp.xcodeprojClaude ejecutará la herramienta xcode-test con el esquema identificado:
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: [First scheme from output]
Destination: platform=iOS Simulator,name=iPhone 14Luego, Claude usará la herramienta xcode-archive para crear un archivo:
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: [First scheme from output]
Configuration: Release
ArchivePath: /Users/username/Desktop/MyApp.xcarchiveEste flujo de trabajo demuestra cómo encadenar varias herramientas, utilizando la salida de una herramienta para informar los parámetros de otra.
Mensaje de usuario a Claude:
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 Flujo de trabajo esperado:
Claude primero obtendrá la lista de dispositivos:
listDevices: trueClaude identificará su dispositivo físico y ejecutará la aplicación en él:
Project path: /Users/username/Projects/MyApp/MyApp.xcodeproj
Scheme: MyApp
Device: "Your iPhone" (or the device UUID)
StreamLogs: truePara un relanzamiento rápido sin necesidad de reconstruir:
Device: "Your iPhone"
DirectBundleId: "com.example.myapp"
SkipBuild: trueEsta herramienta puede ejecutar comandos relacionados con Xcode, lo que supone riesgos de seguridad. Nota:
Úselo solo con proyectos Xcode confiables.
Tenga cuidado con los proyectos de fuentes desconocidas.
No incluya información confidencial en los parámetros de compilación.
Node.js 16 o superior
npm 6 o superior
Xcode 14 o superior (para todas las funciones)
Xcode 16 o superior (necesario para devicectl y funciones del dispositivo real)
# 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 testInstituto Tecnológico de Massachusetts (MIT)
| 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
