Dos servidores MCP convirtieron a Claude Code en un sistema de compilación de iOS

Una sesión de Claude Code apuntada a un proyecto de iOS sin un servidor MCP de Xcode está ciega. El agente puede leer archivos de Swift, escribir archivos de Swift y ejecutar xcodebuild a través de su herramienta Bash, pero cada error de compilación significa analizar miles de líneas de salida no estructurada. La gestión del simulador se realiza con comandos xcrun simctl en bruto. Los resultados de las pruebas llegan como muros de texto que el agente tiene que escanear en busca de fallos.

Puedes darle a Claude Code una integración completa con Xcode añadiendo dos servidores MCP: XcodeBuildMCP (la versión v2.3.2 anuncia 82 herramientas que cubren compilaciones, pruebas, simuladores y depuración con LLDB) y el MCP nativo de Xcode de Apple incluido con Xcode 26.3 (20 herramientas para operaciones con archivos, diagnósticos y vistas previas de SwiftUI). Cada uno requiere un único comando claude mcp add. Juntos reemplazan el análisis no estructurado de registros de compilación con respuestas JSON estructuradas, dándole al agente ubicaciones precisas de errores, resultados de pruebas por método y control programático de simuladores.

Dos comandos claude mcp add cambiaron eso. MCP (Model Context Protocol) es un estándar abierto, especificado en modelcontextprotocol.io, que permite a los agentes de IA llamar a herramientas en sistemas externos a través de solicitudes y respuestas JSON estructuradas: la misma idea que una API REST, pero diseñada para la comunicación agente-herramienta.⁵

TL;DR

XcodeBuildMCP (de código abierto, actualmente con 82 herramientas MCP según la documentación de la v2.3.2) maneja compilaciones, pruebas, simuladores, despliegue en dispositivos reales y depuración con LLDB sin necesidad de que Xcode esté en ejecución. El MCP nativo de Xcode de Apple (20 herramientas, incluido con Xcode 26.3 como xcrun mcpbridge) se conecta a un proceso de Xcode en ejecución para operaciones con archivos, diagnósticos en tiempo real, búsqueda de documentación, REPL de Swift y vistas previas de SwiftUI. Juntos le dan a Claude Code acceso programático completo a la cadena de herramientas de desarrollo de iOS: JSON estructurado en lugar de análisis de registros, llamadas a herramientas en lugar de comandos de shell. La configuración toma menos de 2 minutos.

El problema

Claude Code es excepcional leyendo y escribiendo Swift. Comprende los patrones de SwiftUI, las relaciones de SwiftData y la concurrencia de Swift 6. Pero estaba ciego ante el sistema de compilación.

Cuando una compilación fallaba, el agente tenía que:

1. Ejecutar xcodebuild mediante Bash
2. Analizar miles de líneas de salida no estructurada
3. Esperar haber encontrado el error real entre el ruido
4. Adivinar qué archivo y qué línea causaron el fallo

Cuando quería ejecutar pruebas:

1. El agente construye el comando xcodebuild test completo de memoria
2. Analizar el paquete xcresult (o más probablemente, el stdout en bruto)
3. Intentar averiguar qué pruebas pasaron y cuáles fallaron

El flujo de trabajo equivalía a pedirle a un desarrollador que escribiera código leyendo la salida del compilador a través del ojo de una cerradura. La información estaba técnicamente ahí, pero la interfaz era equivocada.

La solución: dos servidores MCP complementarios

XcodeBuildMCP (comunidad, código abierto)

XcodeBuildMCP envuelve xcodebuild y herramientas relacionadas en herramientas MCP estructuradas (82 en el catálogo actual de la v2.3.2). El agente llama a build_sim y recibe de vuelta JSON con errores categorizados, advertencias y ubicaciones de archivos, no un registro de compilación de 3.000 líneas.

Herramientas clave:

Instalación:

claude mcp add XcodeBuildMCP \
  -s user \
  -e XCODEBUILDMCP_SENTRY_DISABLED=true \
  -- npx -y xcodebuildmcp@latest mcp

La opción -s user lo hace global, disponible en cada proyecto sin configuración por proyecto. La variable de entorno desactiva la telemetría (por defecto envía informes de fallos a Sentry; optar por no participar es un paso de higiene único).¹

MCP de Xcode de Apple (nativo, incluido con Xcode 26.3)

Apple incluyó su propio servidor MCP en Xcode 26.3 a través de xcrun mcpbridge. Expone 20 herramientas que se conectan directamente al proceso de Xcode mediante XPC. Advertencia importante: Apple no ha publicado documentación independiente para el servidor MCP a fecha de mayo de 2026. La lista de herramientas siguiente se basa en las pruebas del autor y el análisis preliminar de Rudrank Riyam. Los nombres y capacidades de las herramientas pueden cambiar en futuras versiones de Xcode:

Instalación:

claude mcp add --transport stdio xcode -s user -- xcrun mcpbridge

Requiere Xcode 26.3+.

¿Por qué ambos?

Se solapan en compilaciones y pruebas, pero la arquitectura difiere:

• XcodeBuildMCP funciona de forma independiente a través de la CLI de xcodebuild, sin necesidad de un proceso de Xcode en ejecución. El catálogo es amplio (82 herramientas MCP a fecha de la v2.3.2) y cubre simuladores, dispositivos reales, depuración con LLDB, automatización de UI y andamiaje de proyectos. La arquitectura independiente importa porque permite flujos de trabajo sin interfaz: el agente puede compilar y probar sin abrir Xcode, lo que es más rápido y consume menos memoria del sistema.
• MCP de Xcode de Apple requiere una instancia de Xcode en ejecución y se comunica vía XPC (el marco de comunicación entre procesos de Apple). Proporciona operaciones con archivos dentro del contexto del proyecto de Xcode, diagnósticos de código en tiempo real (no solo salida de compilación) y búsqueda nativa de documentación incluyendo sesiones de la WWDC. El puente XPC importa porque expone el estado interno de Xcode (diagnósticos en vivo, símbolos resueltos, renderizado de vistas previas) al que ninguna herramienta de CLI puede acceder.

Yo uso ambos: XcodeBuildMCP para el ciclo de compilación-prueba-depuración (funciona sin Xcode abierto), y el MCP de Apple cuando necesito búsquedas de documentación, verificación con el REPL de Swift o renderizado de vistas previas de SwiftUI.

Cuando un agente de IA ejecuta xcodebuild mediante Bash, recibe un flujo de texto no estructurado y debe analizarlo heurísticamente, adivinando dónde empiezan y terminan los errores, infiriendo rutas de archivos a partir de coincidencias parciales y esperando que el formato no haya cambiado. Cuando el mismo agente llama a build_sim mediante MCP, recibe una respuesta JSON con errores categorizados, advertencias, rutas de archivos y números de línea en campos predecibles. La tarea del agente pasa del análisis al razonamiento. La diferencia importa más para los agentes basados en LLM: cada carácter de salida de compilación no estructurada consume tokens de la ventana de contexto, lo que significa que un registro de compilación de 3.000 líneas puede agotar la memoria de trabajo antes de que el agente encuentre el único error que importa. Las respuestas JSON estructuradas permiten al agente leer el error directamente en lugar de buscarlo. MCP no hace al agente más inteligente. Hace legible la información que el agente recibe.

La prueba en el mundo real

Ejecuté una verificación de salud completa en mi app Water (SwiftUI + simulación de fluidos con Metal + HealthKit) usando este prompt:

Use the XcodeBuildMCP and Apple Xcode MCP tools to do a full
health check of this project:

1. List available simulators and boot an iPhone 16 Pro
2. Build the project for that simulator
3. Run existing tests and report pass/fail results
4. Search Apple docs for "HealthKit water intake"
5. Use the Swift REPL to verify HKQuantityType(.dietaryWater)

Lo que sucedió

La configuración del simulador usó list_sims, session_set_defaults y boot_sim. El agente descubrió que no existe un iPhone 16 Pro en el runtime de iOS 26 (fue retirado), por lo que cambió automáticamente a un iPhone 17 Pro. La conmutación automática es el tipo de comportamiento adaptativo que se rompe con comandos xcodebuild codificados de forma fija.

La compilación falló inicialmente, el Metal Toolchain no estaba descargado en la nueva instalación de Xcode. El agente detectó esto a partir de la salida estructurada de errores y ejecutó xcodebuild -downloadComponent MetalToolchain para corregirlo. Entonces la compilación tuvo éxito con 3 advertencias:

HomeView.swift:132    UIScreen.main deprecated in iOS 26.0
LogWaterIntent.swift:61   Result of try? is unused

La salida estructurada significó que estas llegaron como advertencias categorizadas con referencias exactas archivo:línea, no enterradas en un registro.

Las pruebas fallaron, pero el fallo fue informativo. La salida estructurada mostró que 5 métodos de prueba referenciaban injectTapRipple(atNormalizedX:), un método que eliminé en un commit anterior. El agente identificó el commit exacto (7657068, "remove tap ripple interaction entirely") y enumeró qué pruebas necesitaban actualizarse. Cero ambigüedad.

La búsqueda de documentación y el REPL de Swift confirmaron que HKQuantityType(.dietaryWater) es válido, devolviendo el identificador HKQuantityTypeIdentifierDietaryWater.

La tabla de resultados

La verificación de salud completa se ejecutó de forma autónoma en aproximadamente 90 segundos, incluyendo el tiempo de arranque del simulador. No abrí Xcode, no copié ningún mensaje de error, no construí ningún comando xcodebuild. Antes de MCP, la misma verificación de salud de cinco pasos requería aproximadamente entre 8 y 10 minutos de participación humana activa: escribir comandos xcodebuild, analizar la salida, cambiar a Xcode para la búsqueda de documentación, abrir Swift Playgrounds para la verificación con el REPL. El ahorro de tiempo no proviene de compilaciones más rápidas (la compilación lleva la misma cantidad de tiempo) sino de eliminar los pasos de análisis con humano-en-el-bucle entre cada etapa.

Estructurado vs. no estructurado: lo que el agente realmente ve

La diferencia es concreta. Aquí está el mismo error de compilación a través de ambas interfaces:

Mediante Bash (salida en bruto de xcodebuild), 47 líneas de ruido rodeando un error:

CompileSwift normal arm64 /Users/.../HomeView.swift
...
/Users/blake/Projects/Water/Water/Views/HomeView.swift:132:9:
warning: 'main' is deprecated: Use UIScreen.main in iOS 16.0+
         ^~~~~~~~
** BUILD FAILED **
The following build commands failed:
  CompileSwift normal arm64 .../FluidRenderer.swift
...

El agente debe analizar miles de líneas, adivinar dónde empiezan y terminan los errores, e inferir rutas de archivos a partir de coincidencias parciales, consumiendo tokens de la ventana de contexto por cada línea de ruido.

Mediante MCP (respuesta estructurada de build_sim), error exacto en campos predecibles (simplificado para ilustración; la respuesta real incluye campos adicionales como duración de la compilación y esquema):

{
  "status": "failed",
  "errors": [{
    "file": "FluidRenderer.swift",
    "line": 89,
    "message": "Cannot find 'MTLPixelFormat' in scope",
    "severity": "error"
  }],
  "warnings": [{
    "file": "HomeView.swift",
    "line": 132,
    "message": "'main' is deprecated in iOS 26.0",
    "severity": "warning"
  }]
}

El agente lee el error directamente, identifica el archivo y la línea, y empieza a razonar sobre la corrección. Sin análisis, sin adivinar, sin tokens desperdiciados. El coste de la ventana de contexto cae de miles de tokens a docenas.

Enseñando al agente

Instalar servidores MCP no es suficiente. El agente necesita saber que las herramientas existen y cuándo preferirlas a los comandos de shell en bruto. Actualicé mi definición de agente ios-developer para incluir orientación explícita:

## Build & Test Tools (XcodeBuildMCP)

Prefer MCP tools over raw xcodebuild commands:

- **Build**: Use `build_sim` / `build_device` for structured errors
- **Test**: Use `test_sim` / `test_device` for pass/fail results
- **Simulators**: Use `list_sims`, `boot_sim`, `open_sim`
- **Debug**: Use `debug_attach_sim`, `debug_stack`, `debug_variables`

## Apple Xcode MCP (mcpbridge)

- **Documentation**: Use `DocumentationSearch` for Apple docs
- **Swift REPL**: Use `ExecuteSnippet` for API verification
- **Previews**: Use `RenderPreview` for headless SwiftUI rendering

Prefer these over WebSearch for Apple API questions
and over Bash `swift` for REPL tasks.

Sin esto, el agente a veces volverá a xcodebuild mediante Bash o usará WebSearch para la documentación de Apple en lugar de la búsqueda nativa. La definición del agente cierra esa brecha.² Para una mirada más amplia sobre cómo estructurar definiciones de agentes junto con hooks, skills y reglas, la guía de Claude Code cubre la jerarquía completa de configuración.

Qué cambia en la práctica

Antes de MCP, mi flujo de trabajo de iOS con Claude Code era:

1. Escribir código con Claude
2. Compilar manualmente en Xcode (o vía xcodebuild en la terminal)
3. Copiar errores de vuelta a Claude
4. Repetir

Después de MCP:

1. Describir lo que quiero
2. Claude escribe el código, lo compila, lee los errores, los corrige, ejecuta las pruebas y verifica el comportamiento de la API
3. Reviso el resultado final

El bucle de compilación-error-corrección que solía requerir mi participación activa ahora ocurre de forma autónoma. El agente no está adivinando qué salió mal a partir de texto en bruto, lee datos estructurados que le dicen exactamente qué falló, dónde y por qué.

El avance no es hacer la IA más inteligente; es darle a la IA acceso estructurado a las herramientas que los desarrolladores ya usan. MCP es el protocolo que hace esto posible, así como los hooks le dieron a Claude Code guardarraíles deterministas (consulta el tutorial de hooks para detalles de implementación), MCP le da interfaces de herramientas deterministas. Xcode no es la primera y no será la última herramienta de desarrollo que se exponga a través de MCP.³

Otros desarrolladores reportan resultados similares con sistemas de compilación basados en MCP. El recorrido detallado de Rudrank Riyam sobre las herramientas MCP de Xcode de Apple confirmó las capacidades de búsqueda de documentación y el REPL de Swift descritas aquí, y señaló la misma limitación de dependencia con XPC.⁶ El ecosistema más amplio de MCP ahora incluye servidores para Docker, PostgreSQL, GitHub y Kubernetes, cada uno siguiendo el mismo patrón de envolver herramientas de CLI en interfaces JSON estructuradas.⁷ La Tech Talk de Apple “Meet agentic coding in Xcode” (que cubre las funciones agénticas de Xcode 26.3) presentó la función como parte de la inversión más amplia de Apple en el desarrollo asistido por IA, posicionando a MCP como la interfaz estándar entre los agentes de IA y las herramientas de desarrollo en lugar de un protocolo de nicho.⁸

La ganancia de eficiencia derivada de las interfaces estructuradas es consistente con la investigación más amplia sobre el uso de herramientas por IA. SWE-bench (2024) de Jimenez et al. descubrió que los agentes con acceso a herramientas estructuradas (herramientas de edición a nivel de archivo, ejecutores de pruebas con salida estructurada) resolvieron significativamente más problemas de GitHub que los agentes limitados a comandos bash con salida no estructurada.⁹ El patrón no es específico de Xcode: el acceso estructurado a herramientas mejora el rendimiento del agente en distintos dominios porque desplaza la tarea del agente del análisis al razonamiento.

Limitaciones y brechas actuales

MCP no es una solución universal. Una contabilidad honesta de lo que no puede hacer:

Sin depuración visual. MCP devuelve datos estructurados sobre errores de compilación y resultados de pruebas, pero no puede mostrarte el estado visual de la app. Un error de diseño donde una vista se renderiza 10 píxeles descentrada no produce ningún error de compilación y pasa todas las pruebas lógicas. Las herramientas screenshot y snapshot_ui en XcodeBuildMCP capturan la pantalla, pero interpretar la corrección visual aún requiere revisión humana (o un modelo de visión separado). El agente puede compilar, ejecutar y probar, pero no puede ver.

Dependencia del proceso de Xcode para el MCP de Apple. El xcrun mcpbridge de Apple requiere una instancia de Xcode en ejecución. Si Xcode falla o se cierra, las llamadas MCP a través de ese servidor dejan de tener éxito (el puente depende del proceso de Xcode). XcodeBuildMCP evita esto usando xcodebuild directamente, pero cualquier herramienta que se conecte a la interfaz XPC de Xcode hereda el ciclo de vida del proceso de Xcode. La implicación práctica es mantener Xcode abierto durante las sesiones que usan búsqueda de documentación o vistas previas de SwiftUI.

Sin conciencia de compilación incremental. La herramienta build_sim ejecuta una compilación completa. No sabe si la compilación anterior tuvo éxito y solo cambió un archivo. El agente recompila desde cero en cada invocación. Para proyectos grandes, esto añade segundos notables por ciclo de compilación en comparación con xcodebuild con soporte de compilación incremental. La sobrecarga es aceptable por la salida estructurada, pero es un coste real.

Inestabilidad de las herramientas MCP de Apple. Cada servidor MCP que conectas es un límite de confianza que estás extendiendo, y las implicaciones de seguridad son reales, el análisis de la superficie de ataque de MCP documenta 50 vulnerabilidades en todo el ecosistema. Apple incluyó el servidor MCP en Xcode 26.3 sin documentación pública. Los nombres de herramientas, formatos de parámetros y estructuras de respuesta pueden cambiar en futuras versiones de Xcode sin advertencias de obsolescencia. Cualquier código que dependa de firmas específicas de herramientas MCP de Apple debe tratarse como provisional. XcodeBuildMCP, al ser de código abierto y mantenido por la comunidad, proporciona interfaces más estables con versionado semántico y registros de cambios.⁴

Sin diagnósticos de firma de código. Los errores de perfil de aprovisionamiento, las discrepancias de certificados y los conflictos de derechos producen algunos de los fallos de compilación más opacos en el desarrollo de iOS. Ninguno de los servidores MCP proporciona un diagnóstico estructurado de los problemas de firma de código más allá del mensaje de error en bruto. El agente recibe “Code signing failed” con una ruta de archivo, pero no “tu perfil de aprovisionamiento expiró el 15 de febrero” o “este derecho requiere un prefijo específico de App ID”. La firma de código sigue siendo un dominio de depuración manual.

Lista de verificación de configuración

Para cualquiera que ejecute Claude Code con proyectos de iOS:

1. Instalar XcodeBuildMCP (requiere Xcode 16+, macOS 14.5+): bash claude mcp add XcodeBuildMCP -s user \ -e XCODEBUILDMCP_SENTRY_DISABLED=true \ -- npx -y xcodebuildmcp@latest mcp

2. Instalar el MCP de Xcode de Apple (requiere Xcode 26.3+): bash claude mcp add --transport stdio xcode \ -s user -- xcrun mcpbridge

3. Verificar que ambos están conectados: bash claude mcp list # XcodeBuildMCP: ... - Connected # xcode: xcrun mcpbridge - Connected

4. Actualizar las definiciones de tu agente para que hagan referencia a las nuevas herramientas (o el agente a veces volverá a comandos de shell).

5. Iniciar una sesión nueva de Claude Code, las herramientas MCP registradas a mitad de sesión no aparecerán en la búsqueda de herramientas hasta el reinicio.

Eso es todo. Dos comandos, acceso completo al sistema de compilación de iOS.

Prueba esto después de la configuración: Pídele a Claude Code que “compile este proyecto para el simulador y reporte cualquier error”. Compara la respuesta con lo que obtienes al ejecutar xcodebuild -scheme YourScheme -sdk iphonesimulator build mediante Bash. La respuesta de MCP categoriza los errores por archivo y gravedad en campos estructurados. La salida en bruto de xcodebuild entierra la misma información en miles de líneas de salida del compilador entrelazada. La diferencia es inmediatamente visible en el primer error de compilación.

Conclusiones clave

Para desarrolladores de iOS que usan agentes de IA:

• El acceso estructurado a herramientas cambia lo que los agentes pueden hacer. La brecha entre “el agente escribe código y espera que tú lo compiles” y “el agente escribe código, lo compila, lee los errores y los corrige” es la brecha entre una herramienta de completado de texto y un compañero de desarrollo. MCP cierra esa brecha al darle al agente JSON estructurado en lugar de registros de compilación no estructurados.

• Dos servidores MCP cubren necesidades complementarias. XcodeBuildMCP funciona sin Xcode abierto (compilaciones sin interfaz, simuladores, depuración). El MCP de Xcode de Apple se conecta a un proceso de Xcode en ejecución (diagnósticos, documentación, vistas previas de SwiftUI). Usa ambos para una cobertura completa del flujo de trabajo de desarrollo de iOS.

Para ingenieros que evalúan MCP para otras cadenas de herramientas:

• El patrón se generaliza más allá de Xcode. Cualquier herramienta de desarrollo que produzca texto no estructurado (compiladores, linters, ejecutores de pruebas, gestores de paquetes) se vuelve más útil para los agentes de IA cuando se envuelve en interfaces MCP estructuradas. El protocolo importa menos que la idea: los agentes razonan mejor cuando la información llega en campos predecibles en lugar de registros con formato variable.

• Las definiciones de agente cierran la brecha de la última milla. Instalar servidores MCP es necesario pero insuficiente. La orientación explícita en las definiciones del agente (“preferir build_sim sobre xcodebuild”) evita que el agente recurra a comandos de shell cuando existen alternativas estructuradas.

El cluster completo del Ecosistema Apple: App Intents vs MCP para la cuestión del enrutamiento entre superficies; servidores MCP junto con apps de iOS para el patrón de servidor en la app; flujo de trabajo agéntico de Foundation Models para la división LLM entre dentro de la app y herramientas; tres superficies para el modelo más amplio de superficies de apps de iOS. El hub está en la Serie del Ecosistema Apple. La guía de Desarrollo de Agentes en iOS cubre el flujo de trabajo completo impulsado por MCP con más detalle, incluyendo gestión de simuladores y patrones basados en pruebas.

Preguntas frecuentes

¿Sigo necesitando tener Xcode instalado para usar MCP con Claude Code?

Sí. Ambos servidores MCP son envoltorios alrededor de la cadena de herramientas de Xcode (xcodebuild, xcrun, simctl). Xcode debe estar instalado y configurado. Los servidores MCP le dan a Claude Code acceso estructurado a estas herramientas, no las reemplazan.

¿XcodeBuildMCP funciona con proyectos solo de SwiftPM?

Sí. XcodeBuildMCP admite tanto proyectos .xcodeproj/.xcworkspace como proyectos de Swift Package Manager. Usa discover_projs para encontrar los tipos de proyecto disponibles, luego build_sim o build_device con el esquema apropiado.

¿Y los pipelines de CI/CD?

Los servidores MCP se ejecutan localmente con Claude Code. Para CI/CD, seguirías usando xcodebuild directamente o herramientas como Fastlane. El enfoque de MCP es específicamente para el bucle de desarrollo interactivo donde un agente de IA necesita retroalimentación estructurada durante el ciclo de código-compilación-prueba.

¿Qué es MCP y por qué importa para las herramientas de desarrollo de IA?

Model Context Protocol (MCP) es un estándar abierto que define cómo los agentes de IA se comunican con herramientas externas a través de solicitudes y respuestas JSON estructuradas. Antes de MCP, los agentes interactuaban con las herramientas de desarrollo ejecutando comandos de shell y analizando su salida de texto no estructurada, un enfoque frágil que se rompe cuando los formatos de salida cambian y desperdicia tokens de la ventana de contexto en ruido. MCP estandariza la interfaz: el agente envía una solicitud estructurada (build_sim con parámetros), y la herramienta devuelve una respuesta estructurada (JSON con errores categorizados, rutas de archivos y números de línea). La tarea del agente pasa del análisis al razonamiento. MCP es para las herramientas de agentes de IA lo que REST fue para las APIs web: un protocolo compartido que permite a cualquier herramienta exponer capacidades estructuradas a cualquier agente.