App Intents vs MCP: A Questão do Roteamento

Dois protocolos, App Intents e MCP, ambos permitem que um agente externo opere o domínio de um app. Eles não se fundem em um só. A questão é qual vai onde, e por que cada protocolo é a resposta certa para seu próprio chamador.

A Apple lançou App Intents para dar à Apple Intelligence uma superfície tipada e declarativa para operar apps de terceiros sem tocar em sua UI.¹ A Anthropic lançou o Model Context Protocol para dar a qualquer LLM uma superfície tipada e mediada por servidor para operar qualquer ferramenta sem tocar em sua UI.² Os formatos são parecidos. Os chamadores não. Tratá-los como uma única superfície produz uma arquitetura que não satisfaz nenhum dos dois.

Os dois posts anteriores deste cluster cobriram cada protocolo isoladamente: App Intents em App Intents são a Nova API da Apple para seu App, MCP em Dois Ecossistemas de Agentes, Uma Lista de Compras. O post em questão é a questão do roteamento. Quando uma capacidade recebe um AppIntent, quando recebe uma ferramenta MCP, quando recebe ambos, e o que permanece exposto apenas dentro do app?

TL;DR

• App Intents são o único caminho para Apple Intelligence, Siri, Shortcuts e a pilha de sugestões do sistema. O sistema os disponibiliza desde a instalação e por meio de atualizações do app, com a doação e indexação de App Shortcuts trazendo-os à tona em sugestões do Spotlight e da Siri.
• Ferramentas MCP são o caminho para todo LLM não-Apple (Claude, ChatGPT, Gemini, modelos locais). O transporte é stdio ou Streamable HTTP, com .mcpb como formato de empacotamento que comumente embarca um servidor stdio local; o host carrega as ferramentas no momento da sessão.
• Ambos os protocolos convergem em um schema tipado, um formato entity → action → result e resolução de parâmetros. Eles divergem em identidade, persistência, latência e superfície de renderização.
• A regra de roteamento: se a capacidade é algo que um usuário poderia pedir à Siri ou invocar via Spotlight, App Intents. Se a capacidade é algo que um desenvolvedor poderia conectar em uma sessão do Claude Code ou em uma execução de agente externo, MCP. A maioria dos apps precisa dos dois para o mesmo domínio.

Dois Protocolos, o Mesmo Formato

Ambos os protocolos definem um contrato de operação entre um chamador externo e o domínio de um app. O contrato tem três partes: o schema (o que o chamador pode pedir), o resolver (como o app encontra as entidades que o schema nomeia) e a action (o que executa e o que volta).

App Intents expressam o contrato em Swift. A superfície do protocolo é AppIntent, AppEntity, AppEnum, com macros @Parameter dirigindo o schema e func perform() retornando o resultado.³ O schema é gerado em tempo de compilação e empacotado no app na instalação. Apple Intelligence, Siri, Shortcuts e Spotlight leem todos o mesmo schema e roteiam uma requisição tipada pelo mesmo ponto de entrada perform().

MCP expressa o contrato em JSON-RPC sobre stdio ou Streamable HTTP. A superfície do protocolo são os métodos tools/list e tools/call, com cada ferramenta declarando um nome, uma descrição e um inputSchema (com a especificação 2025-06-18 adicionando um outputSchema opcional para retornos estruturados).⁴ Um host MCP (Claude Desktop, Claude Code, Cursor, o app desktop ChatGPT) descobre ferramentas no início da sessão e as chama por nome com um payload JSON. O host roda o modelo; o servidor roda a ferramenta.

O formato é o mesmo: schema, resolver, action. A diferença é quem executa cada peça e onde reside a fronteira de confiança. App Intents rodam dentro do processo do app, no dispositivo do usuário, sob as entitlements do app, com o sistema mediando o roteamento das chamadas. Servidores MCP rodam onde quer que o desenvolvedor tenha decidido rodá-los (stdio local, HTTP hospedado, bundle embarcado), com o LLM host mediando o roteamento de chamadas em um conjunto ilimitado de ferramentas.

Onde os Dois Protocolos Discordam

Além do formato superficial, quatro diferenças operacionais importam para o roteamento:

Identidade e persistência. App Intents falam em tipos AppEntity que o sistema pode armazenar, apresentar e re-resolver depois. A entrada de água que salvo hoje via Hey Siri, log 250ml in Water sobrevive a reinicializações, sincroniza entre os dispositivos iCloud do usuário, e pode ser referenciada por outros intents depois (Show me yesterday’s water entries). O sistema rastreia o ID da entidade em todas essas chamadas.³ MCP é em si um protocolo com estado, com gerenciamento de ciclo de vida, e o Streamable HTTP suporta IDs de sessão para continuidade de conexão, mas a identidade durável de domínio é uma responsabilidade do servidor; não há análogo no nível do protocolo aos identificadores AppEntity que um modelo host possa usar como referência entre sessões. MCP suporta resources para dados de referência persistentes, mas a identidade permanece uma responsabilidade do lado do servidor, não um contrato de primeira classe do protocolo.⁴

Latência e bateria. O corpo do perform() do App Intent executa no contexto do app ou da extensão do app, no dispositivo. Qualquer uso de rede vem do próprio código do app ou da camada Apple Intelligence/Siri ao redor, não do contrato do intent em si. Uma ação tipada e on-device retornando um resultado tipado é rápida no caso comum. Ferramentas MCP, mesmo locais, passam por enquadramento JSON-RPC sobre stdio com uma fronteira de processo separada, e ferramentas MCP remotas incorrem em viagens HTTP de ida e volta. O orçamento de latência é diferente. Um App Intent de log 250ml pode completar dentro de uma janela de turn-taking da Siri. Uma ferramenta MCP remota pode ser o gargalo de uma sessão do Claude Code.

Superfície de renderização. App Intents retornam resultados que a Apple Intelligence renderiza na UI do sistema: um banner na Lock Screen, uma resposta da Siri, uma saída do Shortcuts, um resultado do Spotlight. O app não controla como o resultado se apresenta. Ferramentas MCP retornam blocos de conteúdo (texto, imagens, áudio, recursos embarcados ou conteúdo estruturado) que o modelo host lê e decide como expor. Uma sessão do Claude Code pode citar o resultado de volta para o desenvolvedor, resumi-lo ou alimentá-lo em uma chamada subsequente. A decisão de renderização vive na camada do modelo.

Descobribilidade. A Apple Intelligence disponibiliza App Intents desde a instalação, com a doação e indexação de App Shortcuts trazendo os intents para buscas no Spotlight e sugestões da Siri com base no comportamento do usuário; atualizações do app e entidades dinâmicas ajustam a superfície ao longo do tempo. O usuário nunca digita um nome de ferramenta. Hosts MCP leem ferramentas no início da sessão; o usuário (ou o system prompt) decide quais ferramentas o modelo pode ver. A descoberta é configuração explícita no lado MCP e inferência implícita do sistema no lado App Intents.

Os dois protocolos discordam em identidade, latência, renderização e descoberta: quatro propriedades que decorrem de uma distinção raiz. App Intents servem a um agente em nível de sistema que o usuário não configurou. MCP serve a um agente em nível de sessão que o desenvolvedor configurou. Chamadores diferentes, obrigações diferentes.

A Regra de Roteamento

O mapa de capacidades para um app com ambos os protocolos fica assim:

                    ┌──────────────────────────────────────────┐
                    │      Capacidades de domínio do app        │
                    │                                            │
                    │  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
                    │  │  CRUD   │  │ Queries │  │ Actions │    │
                    │  └─────────┘  └─────────┘  └─────────┘    │
                    └────┬────────────┬────────────┬────────────┘
                         │            │            │
              ┌──────────┴──────┐    │   ┌────────┴──────────┐
              │                 │    │   │                   │
              ▼                 ▼    ▼   ▼                   ▼
       ┌────────────┐    ┌─────────────────────┐    ┌──────────────┐
       │ App Intents │    │ Ambos (AppIntent +  │    │  Ferramentas │
       │   apenas    │    │  wrapper de tool    │    │   MCP       │
       │             │    │  MCP)              │    │   apenas     │
       └────────────┘    └─────────────────────┘    └──────────────┘
            │                       │                       │
       Siri / Spotlight       Capacidades              Claude Code,
       Shortcuts              cross-protocol           agentes externos,
       Apple Intelligence     onde ambos os            tooling de LLM,
       superfícies            chamadores devem         workflows de dev
       proativas              alcançar o mesmo
                              domínio

A regra de roteamento são três perguntas, em ordem.

A capacidade é algo que o usuário pediria à Siri ou invocaria pelo Shortcuts? Se sim, a capacidade precisa de um App Intent. Log 250ml of water, Start a meditation, Add bananas to my list, What did I weigh yesterday são intents porque o usuário pode dizer essas coisas em voz alta, digitá-las no Spotlight ou encadeá-las no Shortcuts. O App Intent não é opcional para essas capacidades; nada mais te leva à superfície de agente de primeira parte da Apple Intelligence.

A capacidade é algo que um agente externo deveria poder dirigir? Se sim, a capacidade precisa de uma ferramenta MCP. Adicionar um item à lista de compras a partir de uma sessão do Claude Code, ler o estado do Get Bananas para o contexto de um agente Cursor, disparar um workflow a partir de um LLM remoto que usa ferramentas são ferramentas MCP porque o chamador não é a Apple Intelligence; o chamador é qualquer LLM que o desenvolvedor tenha conectado. A ferramenta MCP pode envolver a mesma função Swift da camada de domínio que o App Intent chama, mas a superfície do protocolo é JSON-RPC sobre o transporte escolhido pelo desenvolvedor.

A capacidade precisa sobreviver a uma única sessão com identidade estável e conhecida pelo sistema? Se sim, o caminho do App Intent é o ajuste natural, porque o sistema te dá identidade AppEntity, suporte a queries e semântica de persistência de graça. Se não, a ferramenta MCP pode retornar um bloco de conteúdo, deixar a identidade durável a critério do servidor e pular o custo de modelagem de entidades.

A maioria das capacidades não-triviais de um app cai na coluna ambos. Uma capacidade de log de água em Water tem um AppIntent (para que a Siri possa fazer ditado) e uma ferramenta MCP (para que uma sessão do Claude Code possa fazer backfill a partir de um log exportado). Os dois caminhos compartilham uma função Swift; a função não sabe qual chamador a invocou.⁵

O formato, em código, parece um método de domínio e dois wrappers adaptadores que ambos o chamam:

// 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)")

Os dois adaptadores parecem diferentes porque seus chamadores são diferentes. A função que eles chamam é a mesma.

O que Permanece no App

Um conjunto pequeno mas importante de capacidades deve permanecer privado ao app. Roteá-las para qualquer um dos protocolos é um erro.

Capacidades de UI-state. “Abrir a terceira aba”, “rolar até o final”, “destacar esta linha” não são operações de domínio. São primitivas de interação. App Intents oferecem algum suporte a isso por meio de OpensIntent e Shortcuts, mas o ajuste de gênero é fraco; o usuário geralmente quer um resultado, não uma navegação. O suporte do MCP a navegação de UI é ainda pior: o modelo não está dirigindo uma tela, está dirigindo uma ferramenta.

Capacidades que requerem o corpo de uma pessoa no loop. Captura de foto, autenticação biométrica, entrada de PII sensível, qualquer fluxo que exija que o usuário olhe para a tela e toque. O CameraCaptureIntent da Apple existe para fluxos de câmera, mas a intenção de design é lançar uma atividade de captura em primeiro plano, não conceder acesso à câmera em background a um agente. A regra honesta para ambos os protocolos: fluxos de câmera, biometria e entrada sensível devem rodar como UI em primeiro plano com confirmação explícita do usuário, não como chamadas silenciosas de intent ou de tool. Mantenha essas capacidades atrás da UI do app e deixe o agente rotear o usuário para a tela, não através dela.

Trabalho em background de longa duração. App Intents incluem ProgressReportingIntent para expor progresso, e MCP inclui notificações de progresso e primitivas de tarefa, mas a camada de renderização de nenhum dos protocolos foi construída para progresso sustentado em fluxos voltados ao consumidor. O modelo host em uma sessão MCP geralmente expira cadeias de raciocínio bem antes de uma ferramenta de vários minutos terminar. Para trabalho de longa duração voltado ao consumidor, exponha a operação por meio da própria UI do app; deixe os protocolos retornarem a requisição foi enfileirada e linkar para uma tela de status.

Qualquer coisa que toque em dados de outro usuário. A fronteira de confiança em ambos os protocolos é o agente chamador. A Apple Intelligence roda sob a conta iCloud do usuário. MCP roda sob quaisquer credenciais que o desenvolvedor tenha configurado. Operações que cruzam usuários (compartilhamento, acesso multi-conta, ações de admin) não são seguras por nenhum dos protocolos porque a identidade que chama é a identidade errada.

O que Eu Construiria de Forma Diferente

Sabendo a regra de roteamento acima, eu projetaria a camada de domínio em um app Swift do jeito que hoje projeto APIs na fronteira de um serviço. Os métodos de domínio recebem entradas tipadas e retornam saídas tipadas, sem suposições de protocolo embutidas. App Intents envolvem finamente os métodos de domínio com schema @Parameter e cola de perform(). Ferramentas MCP envolvem finamente os mesmos métodos de domínio com schema JSON e enquadramento stdio. Ambos os protocolos são adaptadores finos; o trabalho está no domínio.

Duas consequências decorrem.

A identidade do chamador é uma preocupação de domínio, não de protocolo. O corpo do App Intent recebe parâmetros resolvidos pelo sistema e roda em um contexto onde o usuário passou pelo fluxo de invocação de intent do sistema. O corpo da ferramenta MCP recebe quaisquer credenciais que o host tenha arranjado. Ambos passam para o método de domínio como um argumento caller explícito. O método de domínio aplica autorização, prompts de confirmação e quaisquer outros invariantes de domínio. Nenhum dos protocolos pode fingir que o chamador é o usuário.

Ambos os adaptadores expõem o mesmo conjunto de affordances. A decisão sobre quais capacidades expor a quais chamadores fica capturada em dois manifestos, não em código de protocolo espalhado. Adicionar uma nova capacidade é um método de domínio, dois wrappers adaptadores, duas entradas de manifesto. Remover uma capacidade é simétrico. A matriz acima vira um arquivo real.

A fronteira da plataforma Apple para os próximos anos não é escolher um protocolo. A fronteira é tratar ambos como contratos ortogonais que se compõem na mesma camada de domínio. Agentes da Apple Intelligence têm um conjunto de obrigações para com o usuário (rodam on-device, falam Siri, renderizam pelo sistema). Agentes de LLMs externos têm um conjunto diferente de obrigações para com o desenvolvedor (rodam em qualquer lugar, falam JSON-RPC, renderizam pelo modelo que o desenvolvedor escolheu). Ambos merecem uma superfície tipada para seu app. Nenhum merece ser a única superfície.

Quando Não Construir Ambos

O argumento corta dos dois lados. Alguns apps precisam de um protocolo e não do outro.

Utilitários puros de consumidor sem superfície de desenvolvedor. Uma lanterna. Um identificador de canto de pássaro. Uma trena de realidade aumentada. O usuário pode querer invocar via Siri (App Intents são úteis), mas nenhum desenvolvedor vai conectar isso em um workflow de LLM (MCP seria cosmético).

Ferramentas puras de desenvolvedor sem superfície de usuário final. Um servidor MCP formatador de código. Uma ferramenta de busca em repositórios. Um inspetor de versões de pacotes. O usuário é o desenvolvedor em uma sessão do Claude Code; a Siri e a Apple Intelligence não têm papel.

Apps que não servem bem nenhuma das classes de agentes. Jogos altamente interativos, apps multiplayer em tempo real, apps onde o valor é estar no app e na tela. Nenhum dos protocolos é um bom ajuste; a resposta certa é um app excelente e nenhum contrato de agente.

A decisão não é um ou ambos por padrão. A decisão é para que serve este app e quem mais pode querer operar seu domínio. A resposta pode ser nenhum, um ou ambos. O custo de construir um é pequeno se a camada de domínio estiver bem moldada. O custo de construir ambos, em cima dessa camada de domínio, também é pequeno. O custo de não construir um quando o caso de uso exige é a ausência completa da capacidade naquela superfície de agente.

O que Esse Padrão Significa para a Stack Apple no iOS 26+

Dois aprendizados.

1. Trate App Intents e MCP como contratos ortogonais sobre o mesmo domínio, não como protocolos concorrentes. Apple Intelligence, Siri, Shortcuts e Spotlight são uma classe de chamadores com obrigações em nível de sistema. Claude, Cursor, ChatGPT e o resto são uma segunda classe de chamadores com obrigações em nível de sessão. Ambos merecem acesso tipado. A camada de domínio embaixo deles não muda.

2. A regra de roteamento é quem chama, não o que executa. O App Intent e a ferramenta MCP podem chamar a mesma função Swift. Diferem nas obrigações que o chamador carrega, na renderização que recebem de volta e na persistência que esperam. Acerte a função; deixe as camadas de protocolo finas.

O cluster Apple Ecosystem completo: App Intents tipados para Apple Intelligence, servidores MCP para agentes cross-LLM, Live Activities para a máquina de estados da Lock Screen, padrões Liquid Glass para a camada visual, e shipping multi-plataforma para alcance entre dispositivos. O hub está na Apple Ecosystem Series. Para o contexto mais amplo de iOS-com-agentes-de-IA, veja o iOS Agent Development guide.

FAQ

Quando devo construir um App Intent vs uma ferramenta MCP para a mesma capacidade?

Construa um App Intent quando a capacidade deve alcançar Apple Intelligence, Siri, Shortcuts ou Spotlight. Construa uma ferramenta MCP quando a capacidade deve alcançar LLMs externos (Claude, ChatGPT, agentes em Claude Code ou Cursor). Para capacidades de domínio que devem servir ambas as classes de chamadores, construa ambos como adaptadores finos sobre um método de domínio Swift compartilhado.

App Intents e servidores MCP competem entre si?

Não. App Intents são o caminho para a stack de agentes de primeira parte da Apple; MCP é o caminho para todo outro LLM. A Apple Intelligence não chama ferramentas MCP, e agentes de LLMs externos não podem invocar diretamente App Intents (eles passam pelo sistema). Os dois protocolos servem classes diferentes de chamadores com modelos de confiança diferentes, orçamentos de latência diferentes e superfícies de renderização diferentes.

Um único app pode expor seu domínio através de ambos os protocolos?

Sim, e a maioria dos apps não-triviais que querem alcance completo de agente deveria. Get Bananas (coberto no post sobre servidor MCP) e Water (coberto no post sobre App Intents) são exemplos iniciais. O padrão é uma camada de domínio embaixo, com adaptadores App Intent e adaptadores de ferramenta MCP por cima. Ambos os adaptadores chamam as mesmas funções Swift.

Que estado a Apple Intelligence rastreia que o MCP não rastreia?

A Apple Intelligence rastreia a identidade AppEntity entre chamadas, sessões e reinicializações. O modelo de entidade dá ao sistema referências persistentes que o usuário pode encadear entre intents. O MCP em si é um protocolo com estado, com gerenciamento de ciclo de vida e IDs de sessão no Streamable HTTP, mas a identidade durável de domínio é responsabilidade do lado do servidor, não um contrato de primeira classe do protocolo; o modelo host não recebe um identificador equivalente a AppEntity da superfície do protocolo. O conceito de resources do MCP suporta dados de referência persistentes, mas opera na mesma camada de propriedade do servidor.

Existem capacidades que eu não deveria expor por nenhum dos protocolos?

Sim. Capacidades de UI-state (abrir esta aba, rolar até aqui), capacidades que requerem o corpo de uma pessoa no loop (captura de câmera, autenticação biométrica, entrada sensível), trabalho em background de longa duração e operações que cruzam dados de múltiplos usuários devem todas ficar atrás da UI do app. Ambos os protocolos têm primitivas fracas para isso, e nenhum carrega os sinais de confiança necessários para operar com segurança entre usuários.

Referências