App Intents versus MCP: a questão do roteamento

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 o seu próprio chamador.

A Apple lançou os App Intents para dar à Apple Intelligence uma superfície tipada e declarativa capaz de operar apps de terceiros sem tocar na interface deles.¹ A Anthropic lançou o Model Context Protocol para dar a qualquer LLM uma superfície tipada, mediada por servidor, capaz de operar qualquer ferramenta sem tocar na interface dela.² Os formatos se parecem. Os chamadores, não. Tratar os dois como uma superfície única produz uma arquitetura que não satisfaz nenhum dos lados.

Os dois posts anteriores deste cluster cobriram cada protocolo isoladamente: App Intents em App Intents é a nova API da Apple para o seu app, e MCP em Dois ecossistemas de agentes, uma lista de compras. O post em questão trata da questão do roteamento. Quando um recurso ganha um AppIntent, quando ganha uma ferramenta MCP, quando ganha os dois, e o que fica exposto apenas dentro do app?

TL;DR

• App Intents são o único caminho até a Apple Intelligence, a Siri, o Shortcuts e a pilha de sugestões do sistema. O sistema os disponibiliza desde a instalação e ao longo das atualizações do app; a doação e a indexação dos App Shortcuts levam esses recursos até o Spotlight e as sugestões da Siri.
• Ferramentas MCP são o caminho até todo LLM que não seja da Apple (Claude, ChatGPT, Gemini, modelos locais). O transporte é stdio ou Streamable HTTP, com .mcpb como formato de empacotamento que normalmente entrega um servidor stdio local; o host carrega as ferramentas no início da sessão. A revisão atual da especificação é a 2025-11-25, com um release candidate de 2026-07-28 reorganizando o protocolo em torno de um núcleo sem estado⁶⁷.
• Os dois protocolos convergem em um esquema tipado, em um 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 o recurso é algo que um usuário pode pedir à Siri ou invocar pelo Spotlight, use App Intents. Se o recurso é algo que um desenvolvedor pode ligar a uma sessão do Claude Code ou a uma execução de agente externo, use MCP. A maioria dos apps precisa dos dois para o mesmo domínio.

Dois protocolos, o mesmo formato

Os dois protocolos definem um contrato de operação entre um chamador externo e o domínio de um app. Esse contrato tem três partes: o esquema (o que o chamador pode pedir), o resolvedor (como o app encontra as entidades que o esquema nomeia) e a ação (o que executa e o que volta).

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

O 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 (a especificação 2025-06-18 acrescentou um outputSchema opcional para retornos estruturados, e a revisão 2025-11-25 estabelece o JSON Schema 2020-12 como dialeto padrão, acrescenta ícones de ferramenta como metadados e formaliza a governança para além da Anthropic).⁴⁶ Um host MCP (Claude Desktop, Claude Code, Cursor, o app de desktop do ChatGPT) descobre as ferramentas no início da sessão e as chama pelo nome com um payload JSON. O host roda o modelo; o servidor roda a ferramenta. O protocolo também está em plena transição: o release candidate de 2026-07-28 reconstrói o MCP em torno de um núcleo sem estado que roda em infraestrutura HTTP comum, move o trabalho de longa duração para uma extensão Tasks e acrescenta interface renderizada no servidor por meio do MCP Apps⁷. O argumento de roteamento abaixo sobrevive intacto a essa revisão, porque nada nela muda quem é o chamador.

O formato é o mesmo: esquema, resolvedor, ação. A diferença está em quem executa cada peça e onde fica a fronteira de confiança. Os App Intents rodam dentro do processo do app, no dispositivo do usuário, sob os entitlements do app, com o sistema mediando o roteamento das chamadas. Os servidores MCP rodam onde o desenvolvedor escolheu rodá-los (stdio local, HTTP hospedado, bundle embutido), com o LLM host mediando o roteamento das chamadas por um conjunto ilimitado de ferramentas.

Vale nomear um terceiro chamador com o mesmo formato, porque ele completa o quadro: o modelo local por trás do framework Foundation Models da Apple chama o código do app pelo protocolo Tool dele, um recurso nomeado, descrito e tipado como os outros dois. Uma camada de domínio bem desenhada alimenta as três superfícies sem saber qual delas está chamando.

Onde os dois protocolos discordam

Além do formato de superfície, quatro diferenças operacionais importam para o roteamento:

Identidade e persistência. Os App Intents falam em tipos AppEntity que o sistema consegue armazenar, apresentar e resolver de novo mais tarde. O registro de água que eu salvo hoje com E aí Siri, registre 250 ml no Water sobrevive a reinicializações, sincroniza entre os dispositivos iCloud do usuário e pode ser referenciado depois por outros intents (Mostre meus registros de água de ontem). O sistema acompanha o ID da entidade em todas essas chamadas,³ e o iOS 27 estende a história pelo hardware: uma entidade que adota SyncableEntity carrega um identificador consistente entre os dispositivos de um usuário, então a Siri consegue passar uma conversa sobre o mesmo objeto do iPhone para o Mac e daí para o Watch.⁸ O MCP é, em si, um protocolo com estado e gerenciamento de ciclo de vida, e o Streamable HTTP dá suporte a IDs de sessão para continuidade de conexão, mas identidade durável de domínio é assunto do servidor; não existe análogo em nível de protocolo aos identificadores AppEntity em que um modelo host possa se apoiar entre sessões. O MCP oferece resources para dados de referência persistentes, e a especificação 2025-11-25 acrescenta tasks experimentais para rastrear requisições duráveis, mas a identidade dos objetos de domínio segue sendo responsabilidade do lado do servidor, e não um contrato de primeira classe do protocolo.⁴⁶ A disciplina por baixo é a mesma que vale dentro da própria camada de dados do app: identificadores estáveis que sobrevivem ao processo, tratados para SwiftData em disciplina de esquema.

Latência e bateria. O corpo perform() de um App Intent executa no contexto do app ou de uma extensão de app, no dispositivo. Qualquer uso de rede vem do código do próprio app ou da camada de Apple Intelligence/Siri em volta, não do contrato de intent em si. Uma ação tipada, local, devolvendo um resultado tipado, é rápida no caso comum. Ferramentas MCP, mesmo as locais, passam pelo enquadramento JSON-RPC via stdio com uma fronteira de processo separada, e ferramentas MCP remotas custam idas e vindas de HTTP. O orçamento de latência é outro. Um App Intent de registre 250 ml consegue terminar dentro da janela de um turno de conversa com a Siri. Uma ferramenta MCP remota pode ser o gargalo de uma sessão do Claude Code.

Superfície de renderização. Os App Intents devolvem resultados que a Apple Intelligence renderiza na interface do sistema: um banner na tela bloqueada, uma resposta da Siri, uma saída do Shortcuts, um resultado do Spotlight. O app não controla como o resultado se apresenta. As ferramentas MCP devolvem blocos de conteúdo (texto, imagens, áudio, recursos embutidos ou conteúdo estruturado) que o modelo host lê e sobre os quais 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 seguinte. A decisão de renderização mora na camada do modelo.

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

Os dois protocolos discordam em identidade, latência, renderização e descoberta: quatro propriedades que decorrem de uma única distinção de raiz. Os App Intents servem a um agente em nível de sistema que o usuário não configurou. O 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 recursos de um app com os dois protocolos fica assim:

                    ┌──────────────────────────────────────────┐
                    │           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

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

O recurso é algo que o usuário pediria à Siri ou invocaria pelo Shortcuts? Se sim, o recurso precisa de um App Intent. Registre 250 ml de água, Comece uma meditação, Adicione bananas à minha lista, Quanto eu pesava ontem são intents porque o usuário pode falá-los em voz alta, digitá-los no Spotlight ou encadeá-los no Shortcuts. Para esses recursos o App Intent não é opcional; nada mais leva você até a superfície de agente própria da Apple Intelligence.

O recurso é algo que um agente externo deveria conseguir dirigir? Se sim, o recurso 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 do 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 é o LLM que o desenvolvedor ligou ali. 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.

O recurso precisa sobreviver a uma única sessão, com identidade estável e conhecida pelo sistema? Se sim, o caminho do App Intent é o encaixe natural, porque o sistema entrega de graça identidade AppEntity, suporte a consultas e semântica de persistência. Se não, a ferramenta MCP pode devolver um bloco de conteúdo, deixar a identidade durável a critério do servidor e economizar o custo de modelar entidades.

A maioria dos recursos não triviais de um app cai na coluna dos dois. Um recurso de registro de água no Water tem um AppIntent (para a Siri poder tomar o ditado) e uma ferramenta MCP (para uma sessão do Claude Code poder 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.⁵

Em código, o formato fica como um método de domínio e dois invólucros de adaptador que 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 fica dentro do app

Um conjunto pequeno, porém importante, de recursos deve continuar privado ao app. Rotear esses recursos para qualquer um dos protocolos é um erro.

Recursos de estado de interface. “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. Os App Intents suportam parte disso por OpensIntent e Shortcuts, mas o encaixe de gênero é ruim; o usuário quase sempre quer um resultado, não uma navegação. O suporte do MCP à navegação de interface é ainda pior: o modelo não está dirigindo uma tela, está dirigindo uma ferramenta.

Recursos que exigem o corpo de uma pessoa no circuito. Captura de foto, autenticação biométrica, entrada de dados pessoais sensíveis, 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 projeto é lançar uma atividade de captura em primeiro plano, e não conceder acesso à câmera em segundo plano para um agente. A regra honesta para os dois protocolos: câmera, biometria e fluxos de entrada sensível devem rodar como interface em primeiro plano, com confirmação explícita do usuário, e não como chamadas silenciosas de intent ou de ferramenta. Mantenha esses recursos atrás da interface do app e deixe o agente levar o usuário até a tela, e não através dela.

Trabalho de longa duração em segundo plano. Os dois protocolos ganharam primitivas de verdade aqui, e a conta passou de “nunca” para “com a maquinaria do protocolo, de forma deliberada”. Do lado da Apple, o LongRunningIntent do iOS 27 deixa um intent rodar além do limite de 30 segundos em segundo plano do sistema, com a condição de reportar progresso (o protocolo refina ProgressReportingIntent), com as Live Activities renderizando esse progresso⁸. Do lado do MCP, a especificação 2025-11-25 acrescenta tasks experimentais para requisições duráveis, com polling e recuperação adiada do resultado, promovidas a uma extensão Tasks no release candidate de 2026-07-28⁶⁷. A fronteira honesta agora: use as primitivas quando o chamador iniciou o trabalho e espera acompanhá-lo; mantenha o trabalho atrás da interface do próprio app quando o “progresso” de que um consumidor precisa for mais rico do que uma porcentagem, ou quando um modelo host estouraria o tempo da cadeia de raciocínio dele esperando. A requisição foi enfileirada, aqui está a tela de status continua sendo o valor de retorno certo para qualquer coisa em aberto.

Qualquer coisa que toque os dados de outro usuário. Nos dois protocolos, a fronteira de confiança é o agente que chama. A Apple Intelligence roda sob a conta iCloud do usuário. O MCP roda sob as credenciais que o desenvolvedor ligou ali. Operações que atravessam usuários (compartilhamento, acesso multiconta, ações administrativas) não são seguras por nenhum dos dois protocolos, porque a identidade que chama é a identidade errada.

O que eu construiria de outro jeito

Sabendo da regra de roteamento acima, eu desenharia a camada de domínio de um app Swift do jeito que hoje desenho APIs na fronteira de um serviço. Os métodos de domínio recebem entradas tipadas e devolvem saídas tipadas, sem premissas de protocolo embutidas. Os App Intents envolvem finamente os métodos de domínio com o esquema @Parameter e a cola do perform(). As ferramentas MCP envolvem finamente esses mesmos métodos de domínio com esquema JSON e enquadramento stdio. Os dois protocolos são adaptadores finos; o trabalho está no domínio.

Daí decorrem duas consequências.

A identidade do chamador é assunto de domínio, não de protocolo. O corpo do App Intent recebe parâmetros resolvidos pelo sistema e roda em um contexto em que o usuário passou pelo fluxo de invocação de intents do sistema. O corpo da ferramenta MCP recebe as credenciais que o host arranjou. Os dois repassam isso ao método de domínio como um argumento caller explícito. O método de domínio impõe autorização, confirmações e quaisquer outras invariantes do domínio. Nenhum dos protocolos tem o direito de fingir que o chamador é o usuário.

Os dois adaptadores expõem o mesmo conjunto de possibilidades. A decisão de quais recursos expor a qual chamador fica registrada em dois manifestos, e não espalhada por código de protocolo. Adicionar um recurso novo é um método de domínio, dois invólucros de adaptador, duas entradas de manifesto. Remover um recurso é simétrico. A matriz acima vira um arquivo de verdade.

A fronteira da plataforma da Apple para os próximos anos não é escolher um protocolo. A fronteira é tratar os dois 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 pela Siri, renderizam pelo sistema). Agentes LLM externos têm outro conjunto de obrigações com o desenvolvedor (rodam em qualquer lugar, falam JSON-RPC, renderizam pelo modelo que o desenvolvedor escolheu). Os dois merecem uma superfície tipada para dentro do seu app. Nenhum merece ser a única superfície.

Quando não construir os dois

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

Utilitários puramente de consumo, sem superfície para desenvolvedores. Uma lanterna. Um identificador de cantos de pássaros. Uma trena em realidade aumentada. O usuário pode querer invocar isso pela Siri (App Intents são úteis), mas nenhum desenvolvedor vai ligar isso a um workflow com LLM (o MCP seria cosmético).

Ferramentas puramente de desenvolvimento, sem superfície para o usuário final. Um servidor MCP que formata código. Uma ferramenta de busca em repositório. Um inspetor de versões de pacotes. Aqui o usuário é o desenvolvedor em uma sessão do Claude Code; a Siri e a Apple Intelligence não têm papel algum.

Apps que não servem bem a nenhuma das classes de agente. Jogos muito interativos, apps multijogador em tempo real, apps cujo valor está em estar dentro do app e na tela. Nenhum dos protocolos encaixa bem; a resposta certa é um ótimo app e nenhum contrato de agente.

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

O que esse padrão significa para a pilha da Apple no iOS 26+

Duas conclusões.

1. Trate App Intents e MCP como contratos ortogonais sobre o mesmo domínio, e 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. As duas merecem acesso tipado. A camada de domínio por baixo delas não muda.

2. A regra de roteamento é sobre quem chama, não sobre o que roda. 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 Apple Ecosystem completo: App Intents tipados para a Apple Intelligence, servidores MCP para agentes em vários LLMs, Live Activities para a máquina de estados da tela bloqueada, padrões de Liquid Glass para a camada visual, e publicação multiplataforma para o alcance entre dispositivos. O hub está na série Apple Ecosystem. Para o contexto mais amplo de iOS com agentes de IA, veja o guia de desenvolvimento de agentes em iOS.

Perguntas frequentes

Quando devo construir um App Intent e quando uma ferramenta MCP para o mesmo recurso?

Construa um App Intent quando o recurso precisar alcançar a Apple Intelligence, a Siri, o Shortcuts ou o Spotlight. Construa uma ferramenta MCP quando o recurso precisar alcançar LLMs externos (Claude, ChatGPT, agentes no Claude Code ou no Cursor). Para recursos de domínio que devem servir às duas classes de chamadores, construa os dois como adaptadores finos sobre um método de domínio em Swift compartilhado.

App Intents e servidores MCP competem entre si?

Não. Os App Intents são o caminho até a pilha de agentes própria da Apple; o MCP é o caminho até todos os outros LLMs. A Apple Intelligence não chama ferramentas MCP, e agentes LLM externos não conseguem invocar App Intents diretamente (eles passam pelo sistema). Os dois protocolos servem a classes de chamadores diferentes, 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 pelos dois protocolos?

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

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

A Apple Intelligence acompanha a identidade AppEntity entre chamadas, sessões e reinicializações e, com o SyncableEntity do iOS 27, entre os dispositivos do usuário⁸. O modelo de entidades 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 identidade durável de domínio é responsabilidade do lado do servidor, e não um contrato de primeira classe do protocolo; o modelo host não recebe da superfície do protocolo um identificador equivalente a uma AppEntity. O conceito de resources do MCP e as tasks experimentais da especificação 2025-11-25 dão suporte a dados de referência persistentes e a requisições duráveis, mas ambos operam nessa mesma camada que pertence ao servidor⁶.

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

Existem. Recursos de estado de interface (abra esta aba, role até aqui), recursos que exigem o corpo de uma pessoa no circuito (captura de foto, autenticação biométrica, entrada sensível) e operações que atravessam dados de vários usuários devem ficar atrás da interface do app — nenhum dos protocolos carrega os sinais de confiança necessários para operar com segurança entre usuários. O trabalho de longa duração em segundo plano é a exceção que se moveu: o LongRunningIntent do iOS 27 e a extensão tasks do MCP dão a ele primitivas de verdade agora, então exponha esse trabalho de forma deliberada por essa maquinaria e mantenha atrás da sua própria interface apenas o que for aberto e mais rico do que uma barra de progresso.

Referências