App Intents frente a MCP: la pregunta del enrutamiento

Dos protocolos, App Intents y MCP, permiten que un agente externo opere el dominio de una app. No se funden en uno solo. La pregunta es cuál va dónde, y por qué cada protocolo es la respuesta correcta para su propio llamador.

Apple lanzó App Intents para darle a Apple Intelligence una superficie tipada y declarativa con la que operar apps de terceros sin tocar su interfaz.¹ Anthropic lanzó el Model Context Protocol para darle a cualquier LLM una superficie tipada, mediada por un servidor, con la que operar cualquier herramienta sin tocar su interfaz.² Las formas se parecen. Los llamadores no. Tratarlos como una sola superficie produce una arquitectura que no satisface a ninguno de los dos.

Los dos artículos previos de este clúster cubrieron cada protocolo por separado: App Intents en App Intents es la nueva API de Apple hacia tu app, y MCP en Dos ecosistemas de agentes, una lista de compras. El artículo que tienes delante trata la pregunta del enrutamiento. ¿Cuándo una capacidad recibe un AppIntent, cuándo recibe una herramienta MCP, cuándo recibe ambas, y qué queda expuesto únicamente dentro de la app?

TL;DR

• Los App Intents son el único camino hacia Apple Intelligence, Siri, Shortcuts y la pila de sugerencias del sistema. El sistema los pone a disposición desde la instalación y a través de las actualizaciones de la app; la donación e indexación de App Shortcuts los hace aparecer en Spotlight y en las sugerencias de Siri.
• Las herramientas MCP son el camino hacia todo LLM que no sea de Apple (Claude, ChatGPT, Gemini, modelos locales). El transporte es stdio o Streamable HTTP, y .mcpb es un formato de empaquetado que suele incluir un servidor stdio local; el host carga las herramientas al iniciar la sesión. La revisión vigente de la especificación es 2025-11-25, con una release candidate del 2026-07-28 que reorganiza el protocolo alrededor de un núcleo sin estado⁶⁷.
• Ambos protocolos convergen en un esquema tipado, una forma entity → action → result y la resolución de parámetros. Divergen en identidad, persistencia, latencia y superficie de representación.
• La regla de enrutamiento: si la capacidad es algo que un usuario podría pedirle a Siri o invocar desde Spotlight, van App Intents. Si la capacidad es algo que un desarrollador podría conectar a una sesión de Claude Code o a una ejecución de agente externo, va MCP. La mayoría de las apps necesitan ambos para el mismo dominio.

Dos protocolos, la misma forma

Ambos protocolos definen un contrato de operación entre un llamador externo y el dominio de una app. El contrato tiene tres partes: el esquema (qué puede pedir el llamador), el resolutor (cómo encuentra la app las entidades que nombra el esquema) y la acción (qué se ejecuta y qué regresa).

Los App Intents expresan el contrato en Swift. La superficie del protocolo son AppIntent, AppEntity y AppEnum, con macros @Parameter que impulsan el esquema y func perform() que devuelve el resultado.³ El esquema se genera en tiempo de compilación y se empaqueta dentro de la app al instalarla. Apple Intelligence, Siri, Shortcuts y Spotlight leen todos el mismo esquema y enrutan una solicitud tipada por el mismo punto de entrada perform().

MCP expresa el contrato en JSON-RPC sobre stdio o Streamable HTTP. La superficie del protocolo son los métodos tools/list y tools/call, donde cada herramienta declara un nombre, una descripción y un inputSchema (la especificación 2025-06-18 añadió un outputSchema opcional para retornos estructurados, y la revisión 2025-11-25 establece JSON Schema 2020-12 como dialecto predeterminado, añade iconos de herramientas como metadatos y formaliza la gobernanza más allá de Anthropic).⁴⁶ Un host MCP (Claude Desktop, Claude Code, Cursor, la app de escritorio de ChatGPT) descubre las herramientas al inicio de la sesión y las llama por nombre con una carga útil JSON. El host ejecuta el modelo; el servidor ejecuta la herramienta. Además, el protocolo está en plena transición: la release candidate del 2026-07-28 reconstruye MCP alrededor de un núcleo sin estado que corre sobre infraestructura HTTP común, mueve el trabajo de larga duración a una extensión Tasks y añade interfaz representada del lado del servidor mediante MCP Apps⁷. El argumento de enrutamiento que sigue sobrevive intacto a esa revisión, porque nada de eso cambia quién es el llamador.

La forma es la misma: esquema, resolutor, acción. La diferencia está en quién ejecuta cada pieza y dónde vive la frontera de confianza. Los App Intents corren dentro del proceso de la app, en el dispositivo del usuario, bajo los entitlements de la app, con el sistema mediando el enrutamiento de las llamadas. Los servidores MCP corren donde el desarrollador eligió ejecutarlos (stdio local, HTTP alojado, bundle embebido), con el LLM host mediando el enrutamiento de las llamadas sobre un conjunto ilimitado de herramientas.

Vale la pena nombrar un tercer llamador con la misma forma, porque completa el cuadro: el modelo en el dispositivo detrás del framework Foundation Models de Apple llama al código de la app mediante su protocolo Tool, una capacidad nombrada, descrita y tipada como las otras dos. Una capa de dominio bien formada alimenta las tres superficies sin saber cuál está llamando.

En qué discrepan los dos protocolos

Más allá de la forma superficial, cuatro diferencias operativas importan para el enrutamiento:

Identidad y persistencia. Los App Intents hablan en tipos AppEntity que el sistema puede almacenar, presentar y volver a resolver después. El registro de agua que guardo hoy con Oye Siri, registra 250 ml en Water sobrevive a los reinicios, se sincroniza entre los dispositivos iCloud del usuario y otros intents pueden referenciarlo más tarde (Muéstrame los registros de agua de ayer). El sistema rastrea el ID de la entidad a lo largo de todas esas llamadas,³ y iOS 27 extiende la historia al hardware: una entidad que cumple con SyncableEntity lleva un identificador consistente entre los dispositivos de un usuario, de modo que Siri puede pasar una conversación sobre el mismo objeto del iPhone a la Mac y de ahí al Watch.⁸ MCP es en sí mismo un protocolo con estado y gestión de ciclo de vida, y Streamable HTTP admite IDs de sesión para dar continuidad a la conexión, pero la identidad duradera del dominio es asunto del servidor; no existe un análogo a nivel de protocolo de los identificadores AppEntity en el que un modelo host pueda apoyarse entre sesiones. MCP ofrece resources para datos de referencia persistentes, y la especificación 2025-11-25 añade tasks experimentales para rastrear solicitudes duraderas, pero la identidad de los objetos del dominio sigue siendo una responsabilidad del lado del servidor y no un contrato de primer nivel del protocolo.⁴⁶ La disciplina de fondo es la misma que rige dentro de la propia capa de datos de la app: identificadores estables que sobreviven al proceso, tratados para SwiftData en la disciplina de esquemas.

Latencia y batería. El cuerpo perform() de un App Intent se ejecuta en el contexto de la app o de una extensión de app, en el dispositivo. Cualquier uso de red proviene del código propio de la app o de la capa circundante de Apple Intelligence/Siri, no del contrato del intent en sí. Una acción tipada, en el dispositivo, que devuelve un resultado tipado, es rápida en el caso común. Las herramientas MCP, incluso las locales, pasan por el encuadre JSON-RPC sobre stdio con una frontera de proceso aparte, y las herramientas MCP remotas incurren en viajes de ida y vuelta HTTP. El presupuesto de latencia es distinto. Un App Intent de registra 250 ml puede completarse dentro de una ventana de turno de conversación con Siri. Una herramienta MCP remota podría ser el cuello de botella de una sesión de Claude Code.

Superficie de representación. Los App Intents devuelven resultados que Apple Intelligence representa en la interfaz del sistema: un aviso en la pantalla bloqueada, una respuesta de Siri, una salida de Shortcuts, un resultado de Spotlight. La app no controla cómo se presenta el resultado. Las herramientas MCP devuelven bloques de contenido (texto, imágenes, audio, recursos embebidos o contenido estructurado) que el modelo host lee y sobre los cuales decide cómo mostrarlos. Una sesión de Claude Code podría citarle el resultado al desarrollador, resumirlo o alimentarlo a una llamada posterior. La decisión de representación vive en la capa del modelo.

Descubribilidad. Apple Intelligence pone los App Intents a disposición desde la instalación en adelante; la donación e indexación de App Shortcuts hace que los intents aparezcan en búsquedas de Spotlight y sugerencias de Siri según el comportamiento del usuario, y las actualizaciones de la app y las entidades dinámicas ajustan la superficie con el tiempo. El usuario nunca escribe el nombre de una herramienta. Los hosts MCP leen las herramientas al inicio de la sesión; el usuario (o el prompt del sistema) decide qué herramientas puede ver el modelo. Del lado de MCP el descubrimiento es configuración explícita; del lado de App Intents es inferencia implícita del sistema.

Los dos protocolos discrepan en identidad, latencia, representación y descubrimiento: cuatro propiedades que se desprenden de una sola distinción de raíz. Los App Intents sirven a un agente de nivel de sistema que el usuario no configuró. MCP sirve a un agente de nivel de sesión que el desarrollador sí configuró. Llamadores distintos, obligaciones distintas.

La regla de enrutamiento

El mapa de capacidades de una app con ambos protocolos se ve así:

                    ┌──────────────────────────────────────────┐
                    │           App's domain capabilities       │
                    │                                            │
                    │  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
                    │  │  CRUD   │  │ Queries │  │ Actions │    │
                    │  └─────────┘  └─────────┘  └─────────┘    │
                    └────┬────────────┬────────────┬────────────┘
                         │            │            │
              ┌──────────┴──────┐    │   ┌────────┴──────────┐
              │                 │    │   │                   │
              ▼                 ▼    ▼   ▼                   ▼
       ┌────────────┐    ┌─────────────────────┐    ┌──────────────┐
       │ App Intents │    │ Both (AppIntent +   │    │  MCP tools   │
       │   only      │    │  MCP tool wrapper)  │    │    only      │
       └────────────┘    └─────────────────────┘    └──────────────┘
            │                       │                       │
       Siri / Spotlight       Cross-protocol           Claude Code,
       Shortcuts              capabilities             external agents,
       Apple Intelligence     where both callers       LLM tooling,
       proactive surfaces     should reach the         dev workflows
                              same domain

La regla de enrutamiento son tres preguntas, en orden.

¿Es la capacidad algo que el usuario le pediría a Siri o invocaría desde Shortcuts? Si la respuesta es sí, la capacidad necesita un App Intent. Registra 250 ml de agua, Inicia una meditación, Agrega bananas a mi lista, Cuánto pesaba ayer son intents porque el usuario podría decirlos en voz alta, escribirlos en Spotlight o encadenarlos en Shortcuts. Para esas capacidades el App Intent no es opcional; ninguna otra cosa te lleva a la superficie de agente propia de Apple Intelligence.

¿Es la capacidad algo que un agente externo debería poder manejar? Si la respuesta es sí, la capacidad necesita una herramienta MCP. Agregar un artículo a la lista de compras desde una sesión de Claude Code, Leer el estado de Get Bananas dentro del contexto de un agente de Cursor, Disparar un flujo de trabajo desde un LLM remoto que usa herramientas son herramientas MCP porque el llamador no es Apple Intelligence; el llamador es el LLM que el desarrollador haya conectado. La herramienta MCP puede envolver la misma función Swift de la capa de dominio que llama el App Intent, pero la superficie del protocolo es JSON-RPC sobre el transporte que elija el desarrollador.

¿Necesita la capacidad sobrevivir a una sola sesión con identidad estable y conocida por el sistema? Si la respuesta es sí, el camino del App Intent encaja de forma natural, porque el sistema te da identidad AppEntity, soporte de consultas y semántica de persistencia sin costo. Si la respuesta es no, la herramienta MCP puede devolver un bloque de contenido, dejar la identidad duradera a discreción del servidor y ahorrarse el costo de modelar entidades.

La mayoría de las capacidades no triviales de una app caen en la columna de ambos. Una capacidad de registro de agua en Water tiene un AppIntent (para que Siri pueda tomar dictado) y una herramienta MCP (para que una sesión de Claude Code pueda completar datos desde un registro exportado). Ambas rutas comparten una función Swift; la función no sabe qué llamador la invocó.⁵

En código, la forma se ve como un método de dominio y dos envoltorios adaptadores que lo llaman:

// Domain layer (Swift, no protocol assumptions)
func logWater(amount: Measurement<UnitVolume>, at: Date, caller: Caller) throws -> WaterEntry {
    try guards.requireWritePermission(caller)
    let entry = WaterEntry(amount: amount, timestamp: at)
    try store.insert(entry)
    return entry
}

// Adapter 1: App Intent (Apple Intelligence / Siri / Shortcuts)
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    @Parameter(title: "Amount") var amount: Measurement<UnitVolume>

    func perform() async throws -> some IntentResult & ReturnsValue<WaterEntry> {
        let entry = try domain.logWater(amount: amount, at: .now, caller: .siri)
        return .result(value: entry)
    }
}

// Adapter 2: MCP tool (Claude Desktop / Code / external agent)
// Tool name "log_water" with inputSchema {amount_ml: number}
// Handler:
let entry = try domain.logWater(
    amount: .init(value: ml, unit: .milliliters),
    at: .now,
    caller: .mcp(host: hostName)
)
return .text("Logged \(entry.amount) at \(entry.timestamp)")

Los dos adaptadores se ven distintos porque sus llamadores son distintos. La función que llaman es la misma.

Qué se queda dentro de la app

Un conjunto pequeño pero importante de capacidades debería quedarse privado a la app. Enrutarlas hacia cualquiera de los dos protocolos es un error.

Capacidades de estado de interfaz. «Abre la tercera pestaña», «baja hasta el final», «resalta esta fila» no son operaciones de dominio. Son primitivas de interacción. Los App Intents soportan algo de esto mediante OpensIntent y Shortcuts, pero el género encaja mal; el usuario por lo general quiere un resultado, no una navegación. El soporte de MCP para la navegación de interfaz es aún peor: el modelo no está manejando una pantalla, está manejando una herramienta.

Capacidades que exigen el cuerpo de una persona en el circuito. Captura de fotos, autenticación biométrica, ingreso de datos personales sensibles, cualquier flujo que requiera que el usuario mire la pantalla y toque. El CameraCaptureIntent de Apple existe para flujos de cámara, pero la intención de diseño es lanzar una actividad de captura en primer plano, no conceder acceso a la cámara en segundo plano a un agente. La regla honesta para ambos protocolos: cámara, biometría y flujos de ingreso sensible deben correr como interfaz en primer plano con confirmación explícita del usuario, no como llamadas silenciosas de intent o de herramienta. Mantén esas capacidades detrás de la interfaz de la app y deja que el agente lleve al usuario hasta la pantalla, no a través de ella.

Trabajo de fondo de larga duración. Ambos protocolos ganaron primitivas reales aquí, y el cálculo pasó de «nunca» a «con la maquinaria del protocolo, de forma deliberada». Del lado de Apple, el LongRunningIntent de iOS 27 deja que un intent corra más allá del límite de 30 segundos en segundo plano del sistema, a condición de que reporte progreso (el protocolo refina ProgressReportingIntent), con Live Activities representando ese progreso⁸. Del lado de MCP, la especificación 2025-11-25 añade tasks experimentales para solicitudes duraderas con sondeo y recuperación diferida del resultado, que ascienden a una extensión Tasks en la release candidate del 2026-07-28⁶⁷. La frontera honesta ahora: usa las primitivas cuando el llamador inició el trabajo y espera observarlo; mantén el trabajo detrás de la propia interfaz de la app cuando el «progreso» que necesita un consumidor sea más rico que un porcentaje, o cuando un modelo host agotaría el tiempo de su cadena de razonamiento esperando. La solicitud quedó en cola, aquí está la pantalla de estado sigue siendo el valor de retorno correcto para cualquier cosa de final abierto.

Cualquier cosa que toque los datos de otro usuario. La frontera de confianza en ambos protocolos es el agente que llama. Apple Intelligence corre bajo la cuenta de iCloud del usuario. MCP corre bajo las credenciales que el desarrollador haya conectado. Las operaciones que abarcan varios usuarios (compartir, acceso multicuenta, acciones administrativas) no son seguras por ninguno de los dos protocolos, porque la identidad que llama es la identidad equivocada.

Qué construiría de otra manera

Conociendo la regla de enrutamiento anterior, diseñaría la capa de dominio de una app Swift igual que hoy diseño APIs en la frontera de un servicio. Los métodos de dominio toman entradas tipadas y devuelven salidas tipadas, sin suposiciones de protocolo horneadas dentro. Los App Intents envuelven delgadamente los métodos de dominio con el esquema @Parameter y el pegamento de perform(). Las herramientas MCP envuelven delgadamente esos mismos métodos de dominio con esquema JSON y encuadre stdio. Ambos protocolos son adaptadores delgados; el trabajo está en el dominio.

De ahí se siguen dos consecuencias.

La identidad del llamador es asunto del dominio, no del protocolo. El cuerpo del App Intent recibe parámetros resueltos por el sistema y corre en un contexto donde el usuario pasó por el flujo de invocación de intents del sistema. El cuerpo de la herramienta MCP recibe las credenciales que el host haya dispuesto. Ambos las pasan al método de dominio como un argumento caller explícito. El método de dominio hace cumplir la autorización, los avisos de confirmación y cualquier otra invariante del dominio. Ninguno de los dos protocolos puede fingir que el llamador es el usuario.

Ambos adaptadores exponen el mismo conjunto de posibilidades. La decisión de qué capacidades exponer a qué llamador queda capturada en dos manifiestos, no dispersa en código de protocolo. Agregar una capacidad nueva es un método de dominio, dos envoltorios adaptadores, dos entradas de manifiesto. Quitar una capacidad es simétrico. La matriz de arriba se vuelve un archivo real.

La frontera de la plataforma de Apple para los próximos años no es elegir un protocolo. La frontera es tratar a ambos como contratos ortogonales que se componen en la misma capa de dominio. Los agentes de Apple Intelligence tienen un conjunto de obligaciones hacia el usuario (corren en el dispositivo, hablan Siri, se representan a través del sistema). Los agentes LLM externos tienen otro conjunto de obligaciones hacia el desarrollador (corren donde sea, hablan JSON-RPC, se representan a través del modelo que el desarrollador eligió). Ambos merecen una superficie tipada hacia tu app. Ninguno merece ser la única superficie.

Cuándo no construir ambos

El argumento corta en ambas direcciones. Algunas apps necesitan un protocolo y no el otro.

Utilidades puramente de consumo sin superficie para desarrolladores. Una linterna. Un identificador de cantos de aves. Una cinta métrica de realidad aumentada. El usuario quizá quiera invocarla con Siri (los App Intents son útiles), pero ningún desarrollador la va a conectar a un flujo de trabajo con LLM (MCP sería cosmético).

Herramientas puramente de desarrollo sin superficie para el usuario final. Un servidor MCP que formatea código. Una herramienta de búsqueda en repositorios. Un inspector de versiones de paquetes. Aquí el usuario es el desarrollador en una sesión de Claude Code; Siri y Apple Intelligence no cumplen ningún papel.

Apps que no le sirven bien a ninguna de las dos clases de agentes. Juegos muy interactivos, apps multijugador en tiempo real, apps cuyo valor está en estar dentro de la app y en pantalla. Ninguno de los protocolos encaja bien; la respuesta correcta es una gran app y ningún contrato de agente.

La decisión no es uno o ambos por defecto. La decisión es para qué sirve esta app y quién más podría querer operar su dominio. La respuesta puede ser ninguno, uno o ambos. El costo de construir uno es bajo si la capa de dominio está bien formada. El costo de construir ambos, encima de esa capa de dominio, también es bajo. El costo de no construir uno cuando el caso de uso lo exige es la ausencia total de la capacidad en esa superficie de agente.

Qué significa este patrón para la pila de Apple en iOS 26+

Dos conclusiones.

1. Trata App Intents y MCP como contratos ortogonales sobre el mismo dominio, no como protocolos que compiten. Apple Intelligence, Siri, Shortcuts y Spotlight son una clase de llamadores con obligaciones de nivel de sistema. Claude, Cursor, ChatGPT y los demás son una segunda clase de llamadores con obligaciones de nivel de sesión. Ambas merecen acceso tipado. La capa de dominio debajo de ellas no cambia.

2. La regla de enrutamiento es quién llama, no qué se ejecuta. El App Intent y la herramienta MCP pueden llamar a la misma función Swift. Difieren en las obligaciones que carga el llamador, en la representación que reciben de vuelta y en la persistencia que esperan. Haz bien la función; deja delgadas las capas de protocolo.

El clúster completo de Apple Ecosystem: App Intents tipados para Apple Intelligence, servidores MCP para agentes multi-LLM, Live Activities para la máquina de estados de la pantalla bloqueada, patrones de Liquid Glass para la capa visual, y publicación multiplataforma para el alcance entre dispositivos. El hub está en la serie Apple Ecosystem. Para el contexto más amplio de iOS con agentes de IA, consulta la guía de desarrollo de agentes en iOS.

Preguntas frecuentes

¿Cuándo debo construir un App Intent y cuándo una herramienta MCP para la misma capacidad?

Construye un App Intent cuando la capacidad deba llegar a Apple Intelligence, Siri, Shortcuts o Spotlight. Construye una herramienta MCP cuando la capacidad deba llegar a LLM externos (Claude, ChatGPT, agentes en Claude Code o Cursor). Para las capacidades de dominio que deban servir a ambas clases de llamadores, construye las dos como adaptadores delgados sobre un método de dominio Swift compartido.

¿Compiten entre sí los App Intents y los servidores MCP?

No. Los App Intents son el camino hacia la pila de agentes propia de Apple; MCP es el camino hacia todos los demás LLM. Apple Intelligence no llama herramientas MCP, y los agentes LLM externos no pueden invocar App Intents de forma directa (pasan por el sistema). Los dos protocolos sirven a clases de llamadores distintas, con modelos de confianza distintos, presupuestos de latencia distintos y superficies de representación distintas.

¿Puede una sola app exponer su dominio por ambos protocolos?

Sí, y la mayoría de las apps no triviales que quieran alcance completo de agentes deberían hacerlo. Get Bananas (cubierta en el artículo sobre el servidor MCP) y Water (cubierta en el artículo sobre App Intents) son ejemplos tempranos. El patrón es una capa de dominio debajo, con adaptadores de App Intent y adaptadores de herramientas MCP encima. Ambos adaptadores llaman a las mismas funciones Swift.

¿Qué estado rastrea Apple Intelligence que MCP no rastrea?

Apple Intelligence rastrea la identidad AppEntity entre llamadas, sesiones y reinicios, y con el SyncableEntity de iOS 27 también entre los dispositivos del usuario⁸. El modelo de entidades le da al sistema referencias persistentes que el usuario puede encadenar entre intents. MCP es en sí mismo un protocolo con estado, con gestión de ciclo de vida e IDs de sesión en Streamable HTTP, pero la identidad duradera del dominio es una responsabilidad del lado del servidor y no un contrato de primer nivel del protocolo; el modelo host no obtiene de la superficie del protocolo un identificador equivalente a AppEntity. El concepto de resources de MCP y las tasks experimentales de la especificación 2025-11-25 dan soporte a datos de referencia persistentes y a solicitudes duraderas, pero ambos operan en esa misma capa que pertenece al servidor⁶.

¿Hay capacidades que no debería exponer por ninguno de los dos protocolos?

Sí. Las capacidades de estado de interfaz (abre esta pestaña, baja hasta aquí), las capacidades que exigen el cuerpo de una persona en el circuito (captura de fotos, autenticación biométrica, ingreso sensible) y las operaciones que abarcan datos de varios usuarios deberían quedarse detrás de la interfaz de la app: ninguno de los dos protocolos lleva las señales de confianza necesarias para operar de forma segura entre usuarios. El trabajo de fondo de larga duración es la excepción que se movió: el LongRunningIntent de iOS 27 y la extensión tasks de MCP ya le dan primitivas reales, así que exponlo de forma deliberada mediante esa maquinaria y deja detrás de tu propia interfaz solo el trabajo de final abierto, más rico que una barra de progreso.

Referencias