A2A vs MCP: a diferença entre os protocolos de agentes de IA

A2A vs MCP: a diferença entre os protocolos de agentes de IA

A diferença entre A2A e MCP está em quem fala com quem. O MCP (Model Context Protocol) padroniza a conexão entre um agente e suas ferramentas e dados, como um ERP, um CRM ou uma base de documentos. O A2A (Agent2Agent) padroniza a conversa entre agentes independentes, para que um delegue trabalho a outro. Na maior parte das empresas, o MCP vem primeiro e o A2A só entra quando existem agentes separados que precisam cooperar.

Principais pontos

• MCP resolve a ligação vertical: agente e ferramenta, agente e fonte de dados.
• A2A resolve a ligação horizontal: agente e agente, inclusive de equipes ou fornecedores diferentes.
• Os dois não competem. A documentação do A2A os apresenta como complementares.
• Um único agente com boas ferramentas costuma resolver o processo sem precisar de A2A.
• Em ambos os casos, o risco real está em permissões, dados expostos e falta de registro das decisões, não no protocolo em si.

O que o MCP resolve, segundo a documentação oficial

A introdução oficial do Model Context Protocol descreve o MCP como um padrão aberto para conectar aplicações de IA a sistemas externos. A imagem usada na documentação é a de uma porta padronizada: em vez de escrever uma integração diferente para cada par de aplicação e sistema, você expõe o sistema uma vez como servidor MCP e qualquer cliente compatível consegue usá-lo.

Na prática, um servidor MCP oferece ao agente três tipos de capacidade: ferramentas (ações que o agente pode chamar), recursos (dados que ele pode ler) e prompts (modelos de instrução reutilizáveis). O agente, ou a aplicação que o hospeda, atua como cliente. Quem decide o que o servidor expõe é quem o escreve, e é aí que entra o controle da empresa.

Um exemplo simples: um agente de atendimento precisa consultar o status de um pedido. Com MCP, existe um servidor que expõe uma ferramenta de consulta de pedido, somente leitura. O agente não conhece o banco de dados, conhece apenas a ferramenta, com nome, descrição e parâmetros. Se quiser aprofundar a parte de construção, vale ler sobre como criar um servidor MCP para o sistema interno, começando por leitura.

O que o A2A resolve

A especificação e a documentação do protocolo A2A tratam de outro problema: como um agente descobre, contata e delega tarefas a outro agente que foi construído por outra equipe, em outro framework ou por outro fornecedor. Os agentes não precisam compartilhar código, memória nem lista de ferramentas.

Os conceitos centrais são poucos:

• Agent Card: um documento que o agente publica descrevendo quem ele é, o que sabe fazer e como se autenticar com ele.
• Tarefa: a unidade de trabalho delegada, com ciclo de vida próprio (iniciada, em andamento, aguardando informação, concluída ou falha).
• Mensagens e artefatos: a troca de contexto durante a tarefa e os resultados entregues no final.

Um ponto importante da proposta é a opacidade: o agente que recebe a tarefa não precisa revelar como raciocina, quais ferramentas usa nem o que guarda em memória. Ele apenas se comprometa com uma interface. Isso faz sentido quando os agentes pertencem a organizações diferentes, porque ninguém quer expor a própria lógica interna para colaborar.

O A2A usa padrões comuns da web para transporte e autenticação, o que o aproxima do que equipes de integração já conhecem. Para os detalhes técnicos exatos (formatos, métodos, versões), a fonte correta é sempre a especificação, não resumos de terceiros, incluindo este texto.

Qual é a diferença na prática?

Uma forma útil de separar os dois é perguntar o que está do outro lado da conexão:

• Se do outro lado há uma função determinística (consultar, calcular, gravar), é caso de MCP.
• Se do outro lado há alguém que decide como executar (um agente com seu próprio raciocínio, memória e ferramentas), é caso de A2A.
• Se a chamada deve retornar rápido e com formato previsível, tende a ser MCP.
• Se a tarefa pode demorar, pedir esclarecimentos no meio do caminho ou entregar um resultado composto, tende a ser A2A.
• Se você controla os dois lados e o fluxo é fixo, talvez nenhum dos dois seja necessário: uma chamada direta de API ou um fluxo determinístico basta.

O último item merece atenção. A própria Anthropic, em Building effective agents, recomenda começar pela solução mais simples e só aumentar a complexidade quando houver ganho demonstrável. Sistemas com vários agentes são um degrau acima de um agente com ferramentas, e esse degrau tem custo de operação, depuração e segurança.

Cenário ilustrativo: quando os dois aparecem juntos

Imagine uma empresa de serviços com atendimento por WhatsApp. Este é um cenário ilustrativo, não um caso real.

O agente de atendimento recebe a mensagem de um cliente que quer remarcar uma visita técnica e contestar uma cobrança. Para remarcar, ele usa uma ferramenta de agenda exposta por MCP: consulta horários livres e propõe opções. Aqui há uma função com entrada e saída previsíveis, então MCP resolve bem.

Para a contestação, a regra de negócio pertence à área financeira, que mantém um agente próprio, com acesso ao faturamento, política de estorno e alçadas de aprovação, mantido por outra equipe (ou por um fornecedor). O agente de atendimento não deve ter essas ferramentas nem conhecer essas regras. Ele delega a tarefa ao agente financeiro por A2A, que pode devolver uma resposta pedindo um documento, ou um parecer pronto para revisão humana.

Note que a segunda parte só exige A2A porque existem dois agentes com donos, permissões e ciclos de manutenção diferentes. Se a mesma equipe mantivesse tudo, uma ferramenta MCP de consulta financeira com transferência para um humano talvez fosse mais simples e mais segura. Para o atendimento em si, o texto sobre como integrar IA no WhatsApp da empresa cobre a camada de canal.

Sua empresa precisa dos dois? Um guia de decisão

Use as perguntas abaixo, em ordem. Pare na primeira que resolver o seu caso.

• O processo cabe em um único agente com poucas ferramentas bem definidas? Então comece com ferramentas, via MCP ou API direta, e não adote A2A.
• Os sistemas que o agente precisa usar já têm servidor MCP confiável, ou vale a pena expô-los dessa forma para reaproveitar em vários agentes? Então adote MCP.
• Há um segundo agente que outra equipe ou outro fornecedor mantém, com regras e dados que você não deve ou não consegue copiar? Então avalie A2A para essa fronteira.
• Você consegue explicar, em uma frase, por que dividir em dois agentes é melhor do que ter um agente com mais uma ferramenta? Se não consegue, não divida.
• Existe alguém responsável por cada agente, com registro das tarefas delegadas e forma de interromper o fluxo? Se não existe, a conversa sobre A2A é prematura.

Quem usa o Claude Code ou outro ambiente de desenvolvimento com agentes já está, em geral, no território do MCP. O guia sobre configurar MCP no Claude Code mostra como os escopos de configuração separam o que é pessoal, do projeto e da equipe, um cuidado que vale para qualquer cliente MCP.

Quais riscos os dois protocolos compartilham?

Padronizar a conexão facilita a integração, mas não resolve segurança. Alguns pontos valem para os dois:

• Permissões: cada ferramenta MCP e cada agente A2A deve ter o menor acesso possível. As recomendações do OWASP sobre autorização (negar por padrão, aplicar o menor privilégio, verificar em cada requisição) se aplicam diretamente.
• Confiança no que vem de fora: um servidor MCP de terceiros ou um agente remoto pode devolver conteúdo malicioso ou instruções escondidas. Antes de instalar, vale seguir um roteiro como o de como auditar um servidor MCP.
• Qualidade das ferramentas: descrições vagas levam a chamadas erradas. A Anthropic detalha isso em Writing effective tools for agents, com foco em nomes claros, parâmetros objetivos e respostas enxutas.
• Dados pessoais: ao delegar uma tarefa de um agente para outro, os dados do titular também trafegam. Pela LGPD, a empresa precisa saber quais dados vão para onde, com qual finalidade e quem responde por cada etapa. Isso não muda porque o protocolo é aberto.
• Rastreabilidade: cada chamada de ferramenta e cada tarefa delegada deve gerar registro com quem pediu, o que foi feito e qual foi o resultado. Sem isso, não há como investigar um erro nem provar o que aconteceu.

Para o controle de entrada, saída e ação de um agente, o texto sobre guardrails em agentes de IA é um bom complemento.

Como aplicamos o método: mapear, limitar, pilotar, transferir

Para decidir entre MCP, A2A ou nenhum dos dois, o caminho é o mesmo de qualquer projeto de agente. Primeiro, mapear o processo atual e registrar a linha de base: quem faz, com quais sistemas, onde há decisão humana. Depois, limitar dados e ações: quais ferramentas o agente pode chamar, o que fica somente leitura, o que exige aprovação. Em seguida, pilotar um fluxo real, com logs e uma métrica de sucesso combinada antes. Por fim, transferir a operação e decidir se expande, ajusta ou para.

Nesse roteiro, o A2A raramente aparece no primeiro piloto. Ele costuma entrar quando o mapeamento mostra uma fronteira real entre dois responsáveis, e não como ponto de partida. Para definir a métrica e os critérios de decisão do piloto, o guia sobre como medir um piloto de automação com IA ajuda.

Plano em cinco passos para avaliar a necessidade

• Liste os sistemas e fontes de dados que o fluxo toca e marque quais são apenas leitura.
• Liste as decisões que exigem julgamento e quem hoje é dono de cada uma.
• Verifique se alguma dessas decisões pertence a outro time ou fornecedor com regras próprias. Cada fronteira dessas é candidata a A2A.
• Resolva primeiro o que for ferramenta, com MCP ou API, com permissões mínimas e registro.
• Só então teste uma delegação entre agentes, em um fluxo pequeno, com revisão humana no resultado.

Perguntas frequentes

A2A substitui o MCP? Não. Os dois resolvem problemas diferentes: o MCP conecta um agente a ferramentas e dados, e o A2A conecta agentes entre si. A documentação do A2A trata os protocolos como complementares, e um mesmo agente pode usar MCP para suas ferramentas e A2A para falar com outros agentes.

Minha empresa pequena precisa de A2A? Em geral, não. Se um agente com algumas ferramentas bem definidas resolve o fluxo, adicionar um segundo agente só aumenta custo de manutenção e superfície de risco. O A2A faz sentido quando há agentes mantidos por donos diferentes que precisam cooperar sem expor sua lógica interna.

MCP e A2A são seguros por padrão? Nenhum protocolo garante segurança sozinho. A segurança depende de autenticação, permissões mínimas, validação do que entra e sai, e registro das ações. Servidores e agentes de terceiros devem ser avaliados antes do uso, como qualquer integração que toque dados de clientes.

Por onde começar se quero testar agentes na empresa? Comece mapeando um processo real e escolhendo um fluxo pequeno, com ferramentas somente leitura e uma métrica de sucesso definida antes. Se esse piloto funcionar e surgir uma fronteira clara entre dois responsáveis, aí vale avaliar a comunicação entre agentes. Antes disso, o protocolo é um detalhe de implementação, não a decisão principal.

Fontes

• Model Context Protocol: introdução oficial
• Protocolo A2A: documentação oficial
• Anthropic: Building effective agents
• Anthropic: Writing effective tools for agents