App Intents vs MCP: la cuestión del enrutamiento

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

Apple lanzó App Intents para darle a Apple Intelligence una superficie tipada y declarativa con la que operar apps de terceros sin tocar su UI.¹ Anthropic lanzó Model Context Protocol para darle a cualquier LLM una superficie tipada y mediada por servidor con la que operar cualquier herramienta sin tocar su UI.² Las formas son similares. Los invocadores no lo son. Tratarlos como una sola superficie produce una arquitectura que no satisface a ninguno.

Los dos posts anteriores de este clúster cubrieron cada protocolo por separado: App Intents en App Intents son la nueva API de Apple para tu app, MCP en Dos ecosistemas de agentes, una lista de la compra. El post que tienes delante es la cuestión del enrutamiento. ¿Cuándo una capacidad recibe un AppIntent, cuándo recibe una herramienta MCP, cuándo recibe ambas y qué se queda expuesto solo dentro de la app?

TL;DR

• App Intents son el único camino hacia Apple Intelligence, Siri, Shortcuts y la pila de sugerencias del sistema. El sistema los hace disponibles desde la instalación y a través de las actualizaciones de la app, con la donación e indexación de App Shortcuts asomándolos en Spotlight y en las sugerencias de Siri.
• Las herramientas MCP son el camino hacia cualquier LLM no perteneciente a Apple (Claude, ChatGPT, Gemini, modelos locales). El transporte es stdio o Streamable HTTP, con .mcpb como formato de empaquetado que comúnmente lleva un servidor stdio local; el host carga las herramientas en el momento de la sesión.
• 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 la superficie de renderizado.
• La regla de enrutamiento: si la capacidad es algo que un usuario podría pedirle a Siri o invocar desde Spotlight, App Intents. Si la capacidad es algo que un desarrollador podría conectar a una sesión de Claude Code o a la ejecución de un agente externo, 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 invocador externo y el dominio de una app. El contrato tiene tres partes: el esquema (qué puede pedir el invocador), el resolutor (cómo encuentra la app las entidades que el esquema nombra) y la acción (qué se ejecuta y qué se devuelve).

App Intents expresa el contrato en Swift. La superficie del protocolo es AppIntent, AppEntity, AppEnum, con macros @Parameter que conducen el esquema y func perform() devolviendo el resultado.³ El esquema se genera en tiempo de compilación y se empaqueta en la app al instalarla. Apple Intelligence, Siri, Shortcuts y Spotlight leen todos el mismo esquema y enrutan una solicitud tipada a través del 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ñade un outputSchema opcional para retornos estructurados).⁴ 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 un payload JSON. El host ejecuta el modelo; el servidor ejecuta la herramienta.

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. App Intents se ejecutan 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 se ejecutan dondequiera que el desarrollador haya elegido (stdio local, HTTP alojado, bundle integrado), con el host del LLM mediando el enrutamiento de llamadas a través de un conjunto ilimitado de herramientas.

Dónde discrepan los dos protocolos

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

Identidad y persistencia. App Intents habla en tipos AppEntity que el sistema puede almacenar, presentar y volver a resolver más tarde. La entrada de agua que guardo hoy mediante Oye Siri, registra 250 ml en Water sobrevive a los reinicios, se sincroniza entre los dispositivos iCloud del usuario y puede ser referenciada por otros intents después (Muéstrame las entradas de agua de ayer). El sistema rastrea el ID de la entidad a través de todas esas llamadas.³ MCP es en sí mismo un protocolo con estado y gestión del ciclo de vida, y Streamable HTTP admite IDs de sesión para la continuidad de la conexión, pero la identidad de dominio duradera es responsabilidad del servidor; no hay análogo a nivel de protocolo para los identificadores AppEntity con los que un modelo host pueda contar entre sesiones. MCP admite resources para datos de referencia persistentes, pero la identidad sigue siendo una responsabilidad del lado del servidor en lugar de un contrato de protocolo de primera clase.⁴

Latencia y batería. El cuerpo perform() del App Intent se ejecuta en el contexto de la app o de la extensión de la app en el dispositivo. Cualquier uso de red proviene del propio código de la app o de la capa circundante de Apple Intelligence/Siri, no del contrato del intent en sí. Una acción tipada y 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 encuadrado JSON-RPC sobre stdio con un límite de proceso separado, y las herramientas MCP remotas incurren en idas y vueltas HTTP. El presupuesto de latencia es diferente. Un App Intent de registra 250 ml puede completarse dentro de la ventana de turno conversacional de Siri. Una herramienta MCP remota podría ser el cuello de botella de una sesión de Claude Code.

Superficie de renderizado. App Intents devuelve resultados que Apple Intelligence renderiza en la UI del sistema: un banner en la pantalla de bloqueo, 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 integrados o contenido estructurado) que el modelo host lee y decide cómo mostrar. Una sesión de Claude Code podría citar el resultado de vuelta al desarrollador, resumirlo o alimentarlo en una llamada de seguimiento. La decisión de renderizado vive en la capa del modelo.

Descubribilidad. Apple Intelligence hace que App Intents estén disponibles desde la instalación en adelante, con la donación e indexación de App Shortcuts asomando los intents en las búsquedas de Spotlight y en las sugerencias de Siri según el comportamiento del usuario; 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 system prompt) decide qué herramientas puede ver el modelo. El descubrimiento es configuración explícita en el lado MCP e inferencia implícita del sistema en el lado de App Intents.

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

La regla de enrutamiento

El mapa de capacidades para 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, Añade plátanos a mi lista, Cuánto pesé ayer son intents porque el usuario podría decirlos en voz alta, escribirlos en Spotlight o encadenarlos en Shortcuts. El App Intent no es opcional para esas capacidades; nada más te lleva a la superficie del agente de primera parte de Apple Intelligence.

¿Es la capacidad algo que un agente externo debería poder controlar? Si la respuesta es sí, la capacidad necesita una herramienta MCP. Añadir un elemento a la lista de la compra desde una sesión de Claude Code, Leer el estado de Get Bananas en el contexto de un agente Cursor, Disparar un flujo de trabajo desde un LLM remoto que use herramientas son herramientas MCP porque el invocador no es Apple Intelligence; el invocador es cualquier 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 el desarrollador haya elegido.

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

La mayoría de las capacidades no triviales de una app caen en la columna 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 hacer un backfill desde un registro exportado). Las dos rutas comparten una función Swift; la función no sabe qué invocador la llamó.⁵

La forma, en código, se ve como un método de dominio y dos envoltorios adaptadores que ambos 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 diferentes porque sus invocadores son diferentes. La función que llaman es la misma.

Lo que se queda en la app

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

Capacidades de estado de UI. “Abre la tercera pestaña”, “desplaza hasta abajo”, “resalta esta fila” no son operaciones de dominio. Son primitivas de interacción. App Intents soporta algo de esto a través de OpensIntent y Shortcuts, pero el ajuste de género es pobre; el usuario normalmente quiere un resultado, no una navegación. El soporte de MCP para la navegación de UI es aún peor: el modelo no está manejando una pantalla, está manejando una herramienta.

Capacidades que requieren el cuerpo de una persona en el bucle. Captura de fotos, autenticación biométrica, entrada sensible de PII, 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: los flujos de cámara, biométricos y de entrada sensible deberían ejecutarse como UI en primer plano con confirmación explícita del usuario, no como llamadas silenciosas de intent o de herramienta. Mantén estas capacidades detrás de la UI de la app y deja que el agente enrute al usuario hacia la pantalla, no a través de ella.

Trabajo en segundo plano de larga duración. App Intents incluye ProgressReportingIntent para mostrar progreso, y MCP incluye notificaciones de progreso y primitivas de tareas, pero la capa de renderizado de ninguno de los dos protocolos está construida para progreso sostenido en flujos de consumidor. El modelo host en una sesión de MCP normalmente agota el tiempo de las cadenas de razonamiento mucho antes de que termine una herramienta de varios minutos. Para trabajo de larga duración orientado al consumidor, expón la operación a través de la propia UI de la app; deja que los protocolos devuelvan la solicitud fue encolada y enlacen a una pantalla de estado.

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

Lo que construiría diferente

Conociendo la regla de enrutamiento de arriba, diseñaría la capa de dominio en una app Swift de la misma manera en que ahora diseño APIs en la frontera de un servicio. Los métodos de dominio toman entradas tipadas y devuelven salidas tipadas, sin asunciones de protocolo horneadas dentro. Los App Intents envuelven finamente los métodos de dominio con esquema @Parameter y el pegamento de perform(). Las herramientas MCP envuelven finamente los 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 invocador es una preocupación de dominio, no una preocupación de protocolo. El cuerpo del App Intent recibe parámetros resueltos por el sistema y se ejecuta en un contexto donde el usuario ha pasado por el flujo de invocación de intents del sistema. El cuerpo de la herramienta MCP recibe cualesquiera credenciales que el host haya organizado. Ambos pasan a través del método de dominio como un argumento caller explícito. El método de dominio aplica la autorización, los avisos de confirmación y cualesquiera otros invariantes de dominio. Ninguno de los dos protocolos puede pretender que el invocador es el usuario.

Ambos adaptadores muestran el mismo conjunto de funcionalidades. La decisión de qué capacidades exponer a qué invocador queda capturada en dos manifiestos, no en código de protocolo disperso. Añadir una nueva capacidad es un método de dominio, dos envoltorios adaptadores, dos entradas de manifiesto. Eliminar una capacidad es simétrico. La matriz de arriba se convierte en un archivo real.

La frontera de la plataforma 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 con el usuario (se ejecutan en el dispositivo, hablan Siri, renderizan a través del sistema). Los agentes de LLM externos tienen un conjunto distinto de obligaciones con el desarrollador (se ejecutan donde sea, hablan JSON-RPC, renderizan a través del modelo que el desarrollador haya elegido). Ambos merecen una superficie tipada hacia tu app. Ninguno merece ser la única superficie.

Cuándo no construir ambos

El argumento corta en ambos sentidos. Algunas apps necesitan un protocolo y no el otro.

Utilidades puramente de consumidor sin superficie de desarrollador. Una linterna. Un identificador de cantos de pájaros. Una cinta métrica de realidad aumentada. El usuario podría querer invocarla mediante Siri (App Intents son útiles), pero ningún desarrollador la está conectando a un flujo de trabajo de LLM (MCP sería cosmético).

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

Apps que no sirven bien a ninguna clase de agente. Juegos altamente interactivos, apps multijugador en tiempo real, apps donde el valor está en estar dentro de la app y en pantalla. Ninguno de los dos 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é es esta app y quién más podría querer operar su dominio. La respuesta podría ser ninguno, uno o ambos. El coste de construir uno es pequeño si la capa de dominio está bien moldeada. El coste de construir ambos, encima de esa capa de dominio, también es pequeño. El coste de no construir uno cuando el caso de uso lo demanda es la ausencia completa de la capacidad de esa superficie de agente.

Lo que este patrón significa 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 competidores. Apple Intelligence, Siri, Shortcuts y Spotlight son una clase de invocador con obligaciones a nivel de sistema. Claude, Cursor, ChatGPT y los demás son una segunda clase de invocador con obligaciones a nivel de sesión. Ambos merecen acceso tipado. La capa de dominio debajo de ellos 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 invocador, el renderizado que reciben de vuelta y la persistencia que esperan. Acierta con la función; deja que las capas de protocolo sean delgadas.

El clúster Apple Ecosystem completo: App Intents tipados para Apple Intelligence, servidores MCP para agentes multi-LLM, Live Activities para la máquina de estados de la pantalla de bloqueo, patrones de Liquid Glass para la capa visual y envío multiplataforma para alcance multidispositivo. 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 debería construir un App Intent vs una herramienta MCP para la misma capacidad?

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

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

No. App Intents es el camino hacia la pila de agentes de primera parte de Apple; MCP es el camino hacia cualquier otro LLM. Apple Intelligence no llama a herramientas MCP, y los agentes de LLM externos no pueden invocar directamente App Intents (pasan por el sistema). Los dos protocolos sirven a clases de invocador distintas con modelos de confianza distintos, presupuestos de latencia distintos y superficies de renderizado distintas.

¿Puede una sola app exponer su dominio a través de ambos protocolos?

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

¿Qué estado rastrea Apple Intelligence que MCP no?

Apple Intelligence rastrea la identidad AppEntity a través de las llamadas, la sesión y los reinicios. El modelo de entidad 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 del ciclo de vida e IDs de sesión en Streamable HTTP, pero la identidad de dominio duradera es responsabilidad del lado del servidor en lugar de un contrato de protocolo de primera clase; el modelo host no obtiene un identificador equivalente a AppEntity desde la superficie del protocolo. El concepto resources de MCP admite datos de referencia persistentes pero opera en la misma capa propiedad del servidor.

¿Hay capacidades que no debería exponer a través de ninguno de los dos protocolos?

Sí. Las capacidades de estado de UI (abrir esta pestaña, desplazar aquí), las capacidades que requieren el cuerpo de una persona en el bucle (captura de cámara, autenticación biométrica, entrada sensible), el trabajo de larga duración en segundo plano y las operaciones que abarcan los datos de varios usuarios deberían quedarse todas detrás de la UI de la app. Ambos protocolos tienen primitivas débiles para esto, y ninguno carga las señales de confianza necesarias para operar de forma segura entre usuarios.

Referencias