App Intents vs MCP: A questão do roteamento

Gênero: frontier-essay. O texto define uma regra de roteamento para o desenvolvimento agêntico na Apple. Dois protocolos (App Intents e MCP) 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 para 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, 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 atual é 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 a 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 para a Spotlight e para sugestões 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 entrega um servidor stdio local; o host carrega as ferramentas no momento da sessão.
Ambos os protocolos convergem em um schema tipado, no formato entity → action → result e na 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 for algo que um usuário poderia pedir à Siri ou invocar a partir da Spotlight, App Intents. Se a capacidade for algo que um desenvolvedor poderia conectar a uma sessão do Claude Code ou à execução de um agente externo, MCP. A maioria dos apps precisa dos dois para o mesmo domínio.

Dois protocolos, 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 ação (o que executa e o que é retornado).

App Intents expressam o contrato em Swift. A superfície do protocolo é AppIntent, AppEntity, AppEnum, com macros @Parameter definindo o schema e func perform() retornando o resultado.³ O schema é gerado em tempo de compilação e empacotado no app durante a instalação. Apple Intelligence, Siri, Shortcuts e Spotlight leem 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 de 2025-06-18 adicionando um outputSchema opcional para retornos estruturados).⁴ Um host MCP (Claude Desktop, Claude Code, Cursor, o app desktop do ChatGPT) descobre ferramentas no início da sessão e as chama por nome com um payload JSON. O host executa o modelo; o servidor executa a ferramenta.

O formato é o mesmo: schema, resolver, ação. A diferença é quem executa cada parte e onde está a fronteira de confiança. App Intents executam 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 executam onde o desenvolvedor escolheu rodá-los (stdio local, HTTP hospedado, bundle embutido), com o host LLM mediando o roteamento das chamadas em um conjunto ilimitado de ferramentas.

Onde os dois protocolos divergem

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 via NSUbiquitousKeyValueStore e pode ser referenciada por outros intents mais tarde (Show me yesterday’s water entries). O sistema rastreia o ID da entidade em todas essas chamadas.³ MCP é, por si só, um protocolo com estado e gerenciamento de ciclo de vida, e o Streamable HTTP suporta IDs de sessão para continuidade da conexão, mas a identidade de domínio durável é uma preocupação do servidor; não há análogo a nível de protocolo aos identificadores AppEntity com os quais um modelo host possa contar entre sessões. MCP suporta resources para dados de referência persistentes, mas a identidade permanece como responsabilidade do lado do servidor, em vez de um contrato de protocolo de primeira classe.⁴

Latência e bateria. O corpo de perform() do App Intent executa no contexto do app ou de uma 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, no dispositivo, retornando um resultado tipado é rápida no caso comum. Ferramentas MCP, mesmo locais, passam pelo enquadramento JSON-RPC via stdio com uma fronteira de processo separada, e ferramentas MCP remotas incorrem em viagens HTTP. O orçamento de latência é diferente. Um App Intent log 250ml pode completar dentro de uma janela de turno 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 da Spotlight. O app não controla como o resultado é apresentado. Ferramentas MCP retornam blocos de conteúdo (texto, imagens, áudio, recursos embutidos ou conteúdo estruturado) que o modelo host lê e decide como exibir. 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 na 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 o nome de uma 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 divergem 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 se parece com isto:

                    ┌──────────────────────────────────────────┐
                    │       Capacidades de domínio do app       │
                    │                                            │
                    │  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
                    │  │  CRUD   │  │ Queries │  │ Actions │    │
                    │  └─────────┘  └─────────┘  └─────────┘    │
                    └────┬────────────┬────────────┬────────────┘
                         │            │            │
              ┌──────────┴──────┐    │   ┌────────┴──────────┐
              │                 │    │   │                   │
              ▼                 ▼    ▼   ▼                   ▼
       ┌────────────┐    ┌─────────────────────┐    ┌──────────────┐
       │ App Intents │    │ Ambos (AppIntent +  │    │  MCP tools   │
       │   apenas    │    │  MCP tool wrapper)  │    │    apenas    │
       └────────────┘    └─────────────────────┘    └──────────────┘
            │                       │                       │
       Siri / Spotlight       Capacidades              Claude Code,
       Shortcuts              cross-protocolo,         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 a partir do 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 dizê-los em voz alta, digitá-los na Spotlight ou encadeá-los em Shortcuts. O App Intent é não-opcional para essas capacidades; nada mais leva você à superfície do agente nativo da Apple Intelligence.

A capacidade é algo que um agente externo deve poder operar? Se sim, a capacidade precisa de uma ferramenta MCP. Add an item to the shopping list from a Claude Code session, Read Get Bananas state into a Cursor agent context, Trigger a workflow from a remote tool-using LLM 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 dá a você 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 de app não-triviais cai na coluna ambos. Uma capacidade de log de água no Water tem um AppIntent (para que a Siri possa ditar) e uma ferramenta MCP (para que uma sessão do Claude Code possa preencher dados a partir de um log exportado). As duas rotas compartilham uma função Swift; a função não sabe qual chamador a invocou.⁵

A forma, 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 estado de UI. “Abra a terceira aba”, “role até o fim”, “destaque esta linha” não são operações de domínio. São primitivas de interação. App Intents suportam parte disso via OpensIntent e Shortcuts, mas o ajuste de gênero é ruim; o usuário geralmente quer um resultado, não uma navegação. O suporte do MCP para navegação de UI é ainda pior: o modelo não está controlando uma tela, está controlando uma ferramenta.

Capacidades que exigem o corpo de uma pessoa no loop. Captura de fotos, 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 foreground, não conceder acesso à câmera em background para um agente. A regra honesta para ambos os protocolos: fluxos de câmera, biométricos e de entrada sensível devem rodar como UI em foreground com confirmação explícita do usuário, não como chamadas silenciosas de intent ou de ferramenta. 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 mostrar progresso, e MCP inclui notificações de progresso e primitivas de tarefa, mas a camada de renderização de nenhum dos protocolos foi feita para progresso sustentado em fluxos de consumo. O modelo host em uma sessão do MCP geralmente expira cadeias de raciocínio bem antes que uma ferramenta de vários minutos termine. Para trabalho de longa duração voltado ao consumidor, exponha a operação pela própria UI do app; deixe os protocolos retornarem the request was queued e linke para uma tela de status.

Qualquer coisa que toque 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 conectado. Operações que atravessam usuários (compartilhamento, acesso a múltiplas contas, ações administrativas) não são seguras por nenhum dos protocolos porque a identidade chamadora é a identidade errada.

O que eu faria diferente

Sabendo a regra de roteamento acima, eu projetaria a camada de domínio em um app Swift da maneira como agora 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 disso.

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 de quais capacidades expor a quais chamadores é 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 com o usuário (rodam no dispositivo, falam Siri, renderizam pelo sistema). Agentes LLM externos têm um conjunto diferente de obrigações com o desenvolvedor (rodam onde quer que seja, falam JSON-RPC, renderizam pelo modelo que o desenvolvedor escolheu). Ambos merecem uma superfície tipada para o seu app. Nenhum merece ser a única superfície.

Quando não construir os dois

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

Utilitários puros de consumo sem superfície de desenvolvedor. Uma lanterna. Um identificador de canto de pássaros. Uma fita métrica de realidade aumentada. O usuário pode querer invocá-lo via Siri (App Intents são úteis), mas nenhum desenvolvedor vai conectá-lo a 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ório. Um inspetor de versões de pacote. O usuário é o desenvolvedor em uma sessão do Claude Code; Siri e Apple Intelligence não têm papel.

Apps que não servem bem a nenhuma classe de agente. Jogos altamente interativos, apps multiplayer em tempo real, apps em que o valor é estar no app e na tela. Nenhum dos protocolos serve bem; a resposta certa é um ótimo app 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 os dois, sobre essa 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 pontos a levar.

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 chamador com obrigações em nível de sistema. Claude, Cursor, ChatGPT e o restante são uma segunda classe de chamador com obrigações em nível de sessão. Ambos merecem acesso tipado. A camada de domínio abaixo deles não muda.
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. Eles 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 completo do Apple Ecosystem: App Intents tipados para a Apple Intelligence, servidores MCP para agentes cross-LLM, Live Activities para a máquina de estados da Lock Screen, padrões de Liquid Glass para a camada visual e shipping multiplataforma para alcance entre dispositivos. O hub está em Apple Ecosystem Series. Para o contexto mais amplo de iOS com agentes de IA, veja o guia de iOS Agent Development.

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 chamador, construa as duas como adaptadores finos sobre um método compartilhado de domínio em Swift.

App Intents e servidores MCP competem entre si?

Não. App Intents são o caminho para a stack de agentes nativa da Apple; MCP é o caminho para todo outro LLM. A Apple Intelligence não chama ferramentas MCP, e agentes LLM externos não podem invocar diretamente App Intents (eles passam pelo sistema). Os dois protocolos servem a classes diferentes de chamador, 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 dos dois 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 acima. 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 identidade AppEntity entre chamadas, sessão e reinicializações. O modelo de entidade dá ao sistema referências persistentes que o usuário pode encadear entre intents. MCP é, por si só, um protocolo com estado, com gerenciamento de ciclo de vida e IDs de sessão no Streamable HTTP, mas a identidade de domínio durável é uma responsabilidade do lado do servidor, em vez de um contrato de protocolo de primeira classe; 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.

Há capacidades que eu não devo expor por nenhum dos protocolos?

Sim. Capacidades de estado de UI (abrir esta aba, rolar até aqui), capacidades que exigem o corpo de uma pessoa no loop (captura de câmera, auth biométrica, entrada sensível), trabalho em background de longa duração e operações que abrangem dados de múltiplos usuários devem todas permanecer 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

Apple Developer, “App Intents framework”. Superfície para declarar intents, entidades, parâmetros e queries que Apple Intelligence, Siri, Shortcuts e Spotlight podem rotear. ↩
Anthropic, “Model Context Protocol”. Protocolo aberto para exposição tipada de ferramentas entre hosts LLM. O transporte é stdio ou Streamable HTTP; .mcpb é um formato de empacotamento que comumente entrega um servidor stdio local. A especificação cobre tools/list, tools/call, resources e prompts. ↩
Apple Developer, “Creating your first app intent” e “AppEntity”. Protocolo AppIntent, macro @Parameter, ponto de entrada func perform() e AppEntity para identidade persistente. ↩↩
Anthropic, “MCP Specification: Tools (2025-06-18)”, “MCP Architecture” e “Transports (2025-06-18)”. Definições de método JSON-RPC para tools/list e tools/call, inputSchema e outputSchema opcional, responsabilidades do host, gerenciamento de ciclo de vida e transportes stdio / Streamable HTTP. ↩↩
Análise do autor em App Intents são a nova API da Apple para seu app e Dois ecossistemas de agentes, uma lista de compras. O padrão de adaptador duplo (um método de domínio em Swift, dois wrappers de protocolo) é descrito em ambos os posts no nível de implementação para Water e Get Bananas, respectivamente. ↩