App Intents vs MCP: la cuestión del enrutamiento

Género: frontier-essay. La pieza nombra una regla de enrutamiento para el desarrollo agéntico en Apple. Dos protocolos (App Intents y MCP) permiten que un agente externo opere el dominio de una app. No se colapsan en uno solo. La pregunta 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. Tratarlos como una sola superficie produce una arquitectura que no satisface a ninguno.

Las dos publicaciones previas de este cluster 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 compras. Esta publicación trata sobre la cuestión del enrutamiento. ¿Cuándo una capacidad recibe un AppIntent, cuándo recibe una herramienta MCP, cuándo recibe ambas, y qué 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 pone disponibles desde la instalación y mediante actualizaciones de la app, con la donación e indexación de App Shortcuts haciendo que aparezcan en Spotlight y en las sugerencias de Siri.
• Las herramientas MCP son el camino hacia cualquier LLM que no sea de Apple (Claude, ChatGPT, Gemini, modelos locales). El transporte es stdio o Streamable HTTP, con .mcpb como formato de empaquetado que comúnmente incluye 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 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 resolver (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 dirigen el esquema y func perform() que devuelve el resultado.³ El esquema se genera en tiempo de compilación y se incluye en la app durante la instalación. Apple Intelligence, Siri, Shortcuts y Spotlight leen 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 (con la especificación 2025-06-18 añadiendo 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 invoca por nombre con un payload JSON. El host ejecuta el modelo; el servidor ejecuta la herramienta.

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

Donde los dos protocolos no coinciden

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

Identidad y persistencia. App Intents habla con tipos AppEntity que el sistema puede almacenar, presentar y volver a resolver más adelante. La entrada de agua que guardo hoy mediante Hey Siri, registra 250ml en Water sobrevive a reinicios, se sincroniza a través de NSUbiquitousKeyValueStore 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 lo largo de todas esas llamadas.³ MCP es en sí mismo un protocolo con estado y gestión de ciclo de vida, y Streamable HTTP soporta IDs de sesión para continuidad de conexión, pero la identidad de dominio durable es una preocupación que pertenece al servidor; no hay un análogo a nivel de protocolo de los identificadores AppEntity con los que un modelo host pueda contar a través de sesiones. MCP soporta 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 en el dispositivo que devuelve un resultado tipado es rápida en el caso común. Las herramientas MCP, incluso las locales, pasan por encuadre JSON-RPC sobre stdio con una frontera de proceso separada, y las herramientas MCP remotas incurren en viajes de ida y vuelta HTTP. El presupuesto de latencia es diferente. Un App Intent log 250ml puede completarse dentro de una ventana de turno 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 embebidos o contenido estructurado) que el modelo host lee y decide cómo mostrar. Una sesión de Claude Code podría citarle el resultado al desarrollador, resumirlo o introducirlo en una llamada de seguimiento. La decisión de renderizado vive en la capa del modelo.

Descubribilidad. Apple Intelligence pone a App Intents disponibles desde la instalación en adelante, con la donación e indexación de App Shortcuts haciendo que los intents aparezcan en búsquedas de Spotlight y en 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 de MCP e inferencia implícita del sistema en el lado de App Intents.

Los dos protocolos no coinciden en identidad, latencia, renderizado y descubrimiento: cuatro propiedades que se desprenden 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ó. Diferentes invocadores, diferentes obligaciones.

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 250ml de agua, Inicia una meditación, Añade 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. El App Intent no es opcional para esas capacidades; nada más te lleva a la superficie del agente nativo 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ñade un ítem a la lista de compras desde una sesión de Claude Code, Lee el estado de Get Bananas en el contexto de un agente de Cursor, Dispara un workflow desde un LLM remoto que usa 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 invoca el App Intent, pero la superficie del protocolo es JSON-RPC sobre el transporte elegido por 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 es el ajuste natural, porque el sistema te da identidad AppEntity, soporte de queries y semántica de persistencia gratis. Si la respuesta es no, la herramienta MCP puede devolver un bloque de contenido, dejar la identidad durable a discreción del servidor y saltarse el costo de modelar entidades.

La mayoría de las capacidades no triviales de las apps caen en la columna both. 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 backfill desde un log 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 invocan:

// 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 invocadores son distintos. La función a la que llaman es la misma.

Lo que se queda en la app

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

Capacidades de estado de la UI. “Abre la tercera pestaña”, “haz scroll 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 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, ingreso de PII sensible, 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 otorgar 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 ingreso sensible deben correr como UI en primer plano con confirmación explícita del usuario, no como llamadas silenciosas de intent o tool. 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 consumo. El modelo host en una sesión MCP generalmente agota cadenas de razonamiento mucho antes de que termine una herramienta de varios minutos. Para el 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 puesta en cola 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 invoca. Apple Intelligence corre bajo la cuenta de iCloud del usuario. MCP corre bajo cualesquiera credenciales que el desarrollador haya conectado. Las operaciones que abarcan a varios usuarios (compartir, acceso multicuenta, acciones de admin) no son seguras a través de ninguno de los dos protocolos porque la identidad que invoca 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 delgadamente los métodos de dominio con esquema @Parameter y pegamento perform(). Las herramientas MCP envuelven delgadamente los mismos métodos de dominio con esquema JSON y encuadre stdio. Ambos protocolos son adaptadores delgados; el trabajo está en el dominio.

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 intent del sistema. El cuerpo de la herramienta MCP recibe cualesquiera credenciales que el host haya organizado. Ambos 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 de dominio. Ningún protocolo puede pretender que el invocador sea el usuario.

Ambos adaptadores exponen el mismo conjunto de affordances. 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. 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 con el usuario (corren en el dispositivo, hablan con Siri, renderizan a través del sistema). Los agentes externos LLM tienen un conjunto distinto de obligaciones con el desarrollador (corren donde sea, hablan JSON-RPC, renderizan a través de cualquier 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 ambas direcciones. Algunas apps necesitan un protocolo y no el otro.

Utilidades puras de consumo 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 por Siri (App Intents son útiles), pero ningún desarrollador la está conectando a un workflow LLM (MCP sería cosmético).

Herramientas puras de desarrollador sin superficie para el 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 un papel.

Apps que no sirven bien a ninguna de las dos clases de agentes. Juegos altamente interactivos, apps multijugador en tiempo real, apps donde el valor está en estar dentro de la app y en pantalla. Ningún protocolo 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 costo de construir uno es pequeño si la capa de dominio está bien formada. El costo de construir ambos, encima de esa capa de dominio, también es pequeño. El costo de no construir uno cuando el caso de uso lo demanda es la ausencia completa de la capacidad en esa superficie de agente.

Lo que este patrón significa para el stack 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 invoca, 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. Haz bien la función; deja que las capas de protocolo sean delgadas.

El cluster completo del Ecosistema Apple: 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 Liquid Glass para la capa visual y shipping multi-plataforma para alcance multi-dispositivo. El hub está en la Serie del Ecosistema Apple. Para el contexto más amplio de iOS-con-agentes-IA, consulta la guía de Desarrollo de Agentes en iOS.

FAQ

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

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

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

No. App Intents es el camino hacia el stack de agentes de primera mano de Apple; MCP es el camino hacia cualquier otro LLM. Apple Intelligence no llama a herramientas MCP, y los agentes externos LLM no pueden invocar directamente App Intents (van a través del sistema). Los dos protocolos sirven a clases distintas de invocadores 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 (cubierto en la publicación del servidor MCP) y Water (cubierto en la publicación de App Intents) son ejemplos tempranos. El patrón es una capa de dominio debajo, con adaptadores App Intent y adaptadores de herramienta MCP encima. Ambos adaptadores llaman a las mismas funciones Swift.

¿Qué estado rastrea Apple Intelligence que MCP no?

Apple Intelligence rastrea la identidad de AppEntity a través de llamadas, sesiones y reinicios. El modelo de entidad le da al sistema referencias persistentes que el usuario puede encadenar a través de 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 de dominio durable es una 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 soporta 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 protocolos?

Sí. Las capacidades de estado de UI (abrir esta pestaña, hacer scroll hasta aquí), las capacidades que requieren el cuerpo de una persona en el bucle (captura de cámara, autenticación biométrica, ingreso sensible), el trabajo en segundo plano de larga duración, y las operaciones que abarcan 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 requeridas para operar de forma segura entre usuarios.

Referencias