Português (Brasil)

A2A vs MCP: Dois protocolos complementares para o ecossistema emergente de agentes

Este artigo apresenta A2A e MCP — dois protocolos emergentes que estão moldando o futuro dos sistemas de agentes de IA. Ele explica como eles funcionam, como diferem e por que entender essa arquitetura é importante para desenvolvedores, designers e criadores de produtos de IA.

Guamian

Product & Design

4/11/2025

Pare de perder semanas com autenticação de usuários

Lance aplicativos seguros mais rapidamente com o Logto. Integre a autenticação de usuários em minutos e concentre-se no seu produto principal.

Começar

A adoção crescente de agentes de IA — entidades de software autônomas ou semiautônomas que realizam raciocínios e ações em nome dos usuários — está dando origem a uma nova camada na arquitetura de aplicativos.

No início de 2025, emergiram dois protocolos distintos para atender a isso — A2A (Agent-to-Agent) e MCP (Model Context Protocol). Uma maneira simples de entender seus papéis é:

A2A: Como os agentes interagem entre si

MCP: Como os agentes interagem com ferramentas ou contexto externo

referência: https://google.github.io/A2A/#/topics/a2a_and_mcp

Eles abordam o desafio central de construir sistemas com múltiplos agentes, múltiplos LLMs e múltiplas fontes de contexto — todos precisando colaborar.

Uma maneira de enquadrar isso é: “MCP fornece integração vertical (aplicativo-para-modelo), enquanto A2A fornece integração horizontal (agente-para-agente)

Seja você desenvolvedor ou não, qualquer pessoa que construa produtos de IA ou sistemas agenticos deve entender a arquitetura fundamental — porque ela molda como projetamos produtos, interações com usuários, ecossistemas e crescimento a longo prazo.

Este artigo apresenta os dois protocolos de uma maneira simples e fácil de entender e destaca os principais pontos para desenvolvedores e criadores de produtos de IA.

O que é A2A (Agent-to-Agent)?

A2A (Agent-to-Agent) é um protocolo aberto desenvolvido pelo Google e mais de 50 parceiros da indústria. Seu propósito é permitir interoperabilidade entre agentes — independentemente de quem os construiu, onde estão hospedados ou qual framework utilizam.

Mecanismo do protocolo A2A

A2A usa JSON-RPC 2.0 sobre HTTP(S) como mecanismo de comunicação, com suporte para Server-Sent Events (SSE) para transmitir atualizações.

Modelos de comunicação A2A

A2A define um modelo estruturado de como dois agentes interagem. Um agente assume o papel de agente “cliente”, que inicia uma solicitação ou tarefa, e outro atua como agente “remoto”, que recebe a solicitação e tenta cumpri-la. O agente cliente pode primeiro realizar uma descoberta de capacidade para descobrir qual agente é mais adequado para um determinado trabalho.

Aqui vem uma pergunta: como os agentes se descobrem. Cada agente pode publicar um Cartão de Agente (um documento de metadados JSON, frequentemente hospedado em uma URL padrão como /.well-known/agent.json) descrevendo suas capacidades, habilidades, endpoints de API e requisitos de autenticação.

Ao ler um Cartão de Agente, um agente cliente pode identificar um agente parceiro adequado para a tarefa em questão – essencialmente um diretório do que aquele agente conhece ou pode fazer. Uma vez escolhido um agente alvo, o agente cliente formula um objeto de Tarefa para enviar.

referência: https://google.github.io/A2A/#/

Gestão de tarefas

Toda interação no A2A é orientada para a execução de tarefas. Uma tarefa é um objeto estruturado (definido pelo esquema do protocolo) que inclui detalhes da solicitação e acompanha seu estado.

No A2A, cada agente desempenha um dos dois papéis:

Agente cliente: inicia uma tarefa
Agente remoto: recebe e processa a tarefa

As tarefas podem incluir qualquer forma de trabalho: gerar um relatório, recuperar dados, iniciar um fluxo de trabalho. Os resultados são retornados como artefatos, e os agentes podem enviar mensagens estruturadas durante a execução para coordenar ou esclarecer.

Colaboração e negociação de conteúdo

A2A suporta mais do que simples solicitações de tarefas — os agentes podem trocar mensagens ricas e em várias partes que incluem texto, JSON, imagens, vídeo ou conteúdo interativo. Isso permite a negociação de formato com base no que cada agente pode lidar ou exibir.

Por exemplo, um agente remoto pode devolver um gráfico como dados brutos ou uma imagem, ou solicitar a abertura de um formulário interativo. Este design suporta comunicação flexível e agnóstica de modalidade, sem exigir que os agentes compartilhem ferramentas internas ou memória.

Exemplo de uso

Aqui está um exemplo do mundo real de como A2A poderia ser usado em um cenário empresarial:

Um novo funcionário é contratado em uma grande empresa. Múltiplos sistemas e departamentos estão envolvidos na integração:

RH precisa criar um registro e enviar um e-mail de boas-vindas
TI precisa provisionar um laptop e contas da empresa
Instalações precisam preparar uma mesa e um crachá de acesso

Tradicionalmente, essas etapas são tratadas manualmente ou por meio de integrações fortemente acopladas entre sistemas internos.

Em vez de APIs personalizadas entre cada sistema, cada departamento expõe seu próprio agente usando o protocolo A2A:

Agente	Responsabilidade
hr-agent.company.com	Criar registro do funcionário, enviar documentos
it-agent.company.com	Criar conta de e-mail, fazer pedido de laptop
facilities-agent.company.com	Atribuir mesa, imprimir crachá de acesso

Um sistema multiagente — vamos chamá-lo de OnboardingPro (por exemplo, onboarding-agent.company.com) — coordena todo o fluxo de trabalho de integração.

Descoberta: Ele lê o .well-known/agent.json de cada agente para entender as capacidades e autenticação.
Delegação de tarefas:
- Envia uma tarefa createEmployee para o agente de RH.
- Envia tarefas setupEmailAccount e orderHardware para o agente de TI.
- Envia assignDesk e generateBadge para o agente de Instalações.
Atualizações em streaming: Os agentes transmitem progresso usando Server-Sent Events (por exemplo, “laptop enviado”, “mesa atribuída”).
Coleta de artefatos: Resultados finais (por exemplo, crachá PDF, e-mails de confirmação, credenciais de conta) são retornados como artefatos A2A.
Conclusão: O OnboardingPro notifica o gerente de contratação quando a integração é concluída.

O que é MCP (Model Context Protocol)?

MCP (Model Context Protocol), desenvolvido pela Anthropic, aborda um problema diferente: como aplicativos externos podem fornecer contexto estruturado e ferramentas para um agente baseado em modelo de linguagem em tempo de execução.

Em vez de habilitar a comunicação entre agentes, o MCP foca na janela de contexto — a memória de trabalho de um LLM. Seu objetivo é:

Injetar dinamicamente ferramentas, documentos, funções de API, ou estado do usuário relevante na sessão de inferência de um modelo
Permitir que os modelos chamem funções ou busquem documentos sem codificar o prompt ou lógica

Arquitetura chave do MCP

Para entender o MCP, primeiro você precisa entender a arquitetura geral — como todas as partes funcionam juntas.

Host MCP: “A IA com a qual você está falando”

Pense no Host MCP como o próprio aplicativo de IA — como o Claude Desktop ou seu assistente de codificação.

É a interface que você está usando — o lugar onde você digita ou fala.

Quer trazer ferramentas e dados que ajudem o modelo a dar melhores respostas.

Cliente MCP: “O conector”

O Cliente MCP é a peça de software que conecta seu host de IA (como Claude) ao mundo exterior. É como uma central de comutação — gerencia conexões seguras, um-a-um, com diferentes Servidores MCP. Quando a IA quer acessar algo, ela passa pelo cliente.

É útil pensar em ferramentas como ChatGPT, Claude chat, ou Cursor IDE como hosts MCP — eles fornecem a interface com a qual você interage. Por trás dos bastidores, eles usam um cliente MCP para conectar a diferentes ferramentas e fontes de dados através de servidores MCP.

referência: https://modelcontextprotocol.io/introduction

Servidor MCP: “O provedor de ferramentas”

Um Servidor MCP é um pequeno programa focalizado que expõe uma ferramenta ou capacidade específica — como:

Pesquisar arquivos no seu computador
Consultar dados em um banco de dados local
Chamar uma API externa (como clima, finanças, calendário)

Cada servidor segue o protocolo MCP, para que a IA possa entender o que ele pode fazer e como chamá-lo.

Fontes de dados locais: “Seus próprios arquivos e serviços”

Alguns Servidores MCP se conectam a coisas em sua própria máquina — como:

Documentos e pastas
Projetos de código
Bancos de dados ou aplicativos locais

Isso permite que a IA busque, recupere ou compute coisas sem enviar seus dados para a nuvem.

Serviços remotos: “APIs e ferramentas online”

Outros Servidores MCP estão conectados à internet — eles falam com:

APIs (por exemplo, Stripe, Notion, GitHub)
Ferramentas SaaS
Bancos de dados da empresa na nuvem

Assim, a IA pode dizer, por exemplo: “Chame o servidor GitHub e busque a lista de PRs abertos.”

O MCP agora suporta conexão a servidores MCP remotos. Isso significa que um cliente MCP pode ganhar capacidades mais poderosas. Em teoria,

Com o conjunto certo de servidores MCP, os usuários podem transformar todo cliente MCP em um “aplicativo de tudo”.

referência: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

Colocando tudo junto

Agora vamos usar um diagrama para ver como tudo funciona junto.

Você pede algo complexo à IA
A IA (o host) pede ajuda ao cliente
O cliente chama o servidor MCP certo — talvez um que verifique arquivos ou acesse uma API
O servidor envia de volta dados ou executa uma função
O resultado flui de volta para o modelo para ajudá-lo a completar a tarefa

A2A vs MCP — Comparação

Categoria	A2A (Agent-to-Agent)	MCP (Model Context Protocol)
Objetivo Primário	Permitir troca de tarefas entre agentes	Permitir que LLMs acessem ferramentas ou contexto externo
Projetado Para	Comunicação entre agentes autônomos	Aprimorar habilidades de um único agente durante a inferência
Foco	Fluxos de trabalho multiagente, coordenação, delegação	Uso dinâmico de ferramentas, aumento de contexto
Modelo de Execução	Agentes enviam/recebem tarefas e artefatos	LLM seleciona e executa ferramentas em linha durante o raciocínio
Segurança	OAuth 2.0, chaves de API, âmbitos declarativos	Gerenciado na camada de integração de aplicativos
Papel do Desenvolvedor	Construir agentes que expõem tarefas e artefatos via endpoints	Definir ferramentas estruturadas e contexto que o modelo pode usar
Parceiros do Ecossistema	Google, Salesforce, SAP, LangChain, etc.	Anthropic, com adoção emergente em UIs baseadas em ferramentas LLM

Como eles trabalham juntos

Em vez de serem alternativas, A2A e MCP são complementares. Em muitos sistemas, ambos serão utilizados juntos.

Exemplo de fluxo de trabalho

Um usuário envia uma solicitação complexa em uma interface de agente empresarial.
O agente orquestrador usa A2A para delegar subtarefas a agentes especializados (por exemplo, análise, RH, finanças).
Um desses agentes usa MCP internamente para invocar uma função de busca, buscar um documento ou computar algo usando um modelo.
O resultado é retornado como um artefato via A2A, permitindo colaboração de agentes de ponta a ponta com acesso modular a ferramentas.

Essa arquitetura separa comunicação entre agentes (A2A) da invocação de capacidades intra-agente (MCP) — tornando o sistema mais fácil de compor, escalar e proteger.

Conclusão

A2A é sobre agentes falando com outros agentes em uma rede — de forma segura, assíncrona e centrada em tarefas.

MCP é sobre injetar capacidades estruturadas em uma sessão de modelo, permitindo que LLMs raciocinem sobre ferramentas e dados de forma contextual.

Usados juntos, eles suportam sistemas multiagentes composíveis, que são extensíveis e interoperáveis.

Como a infraestrutura base MCP + A2A pode moldar o futuro dos mercados de produtos de agentes

Por fim, quero falar sobre como essa base técnica central pode moldar o futuro do mercado de IA — e o que isso significa para as pessoas que estão construindo produtos de IA.

A mudança da interação humano-computador

Um exemplo claro dessa mudança pode ser visto nos fluxos de trabalho de desenvolvimento e serviço. Com servidores MCP agora integrados em IDEs e agentes de codificação, a maneira como os desenvolvedores interagem com as ferramentas está mudando fundamentalmente.

Anteriormente, um fluxo de trabalho típico envolvia procurar o serviço certo, configurar hospedagem, ler documentação, integrar APIs manualmente, escrever código no IDE e configurar recursos através de um painel de baixo código. Era uma experiência fragmentada, exigindo troca de contexto e sobrecarga técnica em cada etapa.

Agora, com agentes de codificação conectados a MCP, grande parte dessa complexidade pode ser abstraída. Os desenvolvedores podem descobrir e usar ferramentas de maneira mais natural por meio de prompts de conversação. A integração de APIs está se tornando parte do próprio fluxo de codificação — muitas vezes sem precisar de uma interface separada ou configuração manual. (Basta pensar em quão complexo os painéis da AWS ou da Microsoft podem ser). A interação se torna mais suave — mais sobre guiar o comportamento do que montar recursos.

Neste modelo, a interação do usuário ou desenvolvedor passa de configurar recursos para orquestrar comportamentos. Isso muda também o papel do design de produto.

Em vez de usar interfaces para “cobrir” desafios técnicos (por exemplo: “isso é muito difícil de codificar, vamos fazer um painel de configuração”), agora precisamos:

Pensar na experiência de ponta a ponta
Projetar como e quando interações AI + usuário devem se juntar
Deixar que a IA cuide da lógica e guie os usuários através da intenção e do fluxo

O desafio torna-se decidir quando e como a IA e a entrada do usuário devem se juntar, deixar que a IA cuide da lógica e guiar os usuários através da intenção e do fluxo e como inserir as interações certas no momento certo.

Usei um serviço de desenvolvedor e produto de API como exemplo para mostrar como a interação do usuário pode mudar — mas isso se aplica igualmente ao software empresarial. Por muito tempo, as ferramentas de negócios foram complexas e difíceis de usar. A interação por linguagem natural tem o potencial de simplificar muitos desses fluxos de trabalho.

Paradigmas de produtos agenticos e seu impacto no SaaS

Estamos começando a ver um número crescente de servidores MCP surgir. Imagine o Airbnb oferecendo um servidor MCP de reservas, ou o Google Maps expondo um servidor MCP de mapa. Um agente (como cliente MCP) poderia se conectar a muitos desses servidores de uma vez — desbloqueando fluxos de trabalho que anteriormente exigiam integrações personalizadas ou aplicativos rigidamente vinculados.

Comparado à era do SaaS, onde as integrações eram muitas vezes manuais e rígidas, este modelo permite fluxos de trabalho mais autônomos e conexões fluidas entre serviços. Aqui estão dois exemplos:

Design a partir de documentos

Você escreve um PRD no Notion. Um agente Figma lê o documento e automaticamente cria um wireframe que descreve os conceitos principais — sem necessidade de transferência manual.
Pesquisa de concorrentes, de ponta a ponta

Você pede uma análise de concorrentes. Um grupo de agentes busca na web, se inscreve para serviços relevantes em seu nome (com autenticação segura), coleta os resultados e entrega os artefatos de volta — já organizados no seu espaço de trabalho do Notion.

Desafios com limites de autenticação e autorização

Com o aumento das conexões de agente para agente, conexões de cliente MCP para servidor MCP, há muitas necessidades subjacentes sobre autenticação e autorização porque o agente agirá em nome de humanos e usuários e as credenciais devem ser protegidas ao longo desta jornada.

Até agora, existem vários cenários específicos para o novo surgimento de agente para agente e MCP.

Agente vs SaaS & WebsiteApp
Cliente MCP (Agente) vs Servidor MCP
Usuário vs Agente
Agente vs Agente

Outro caso de uso interessante é a federação de identidade múltipla Google mencionou:

Por exemplo, o usuário U está trabalhando com o Agente A, que requer o identificador do sistema A. Se o Agente A depende do Tool B ou Agente B, que requer o identificador do sistema B, o usuário pode precisar fornecer identidades para ambos os sistemas A e B em uma única solicitação. (Suponha que o sistema A seja uma identidade LDAP empresarial e o sistema B seja uma identidade de provedor SaaS).

Logto é um provedor OIDC e OAuth, bem adequado para o futuro das integrações de IA.

Com sua infraestrutura flexível, estamos expandindo ativamente suas capacidades e publicamos uma série de tutoriais para ajudar os desenvolvedores a começar rapidamente.

Tem perguntas?

Entre em contato conosco — ou mergulhe e explore o que você pode construir com o Logto hoje.

Experimente o Logto Cloud gratuitamente

O que é A2A (Agent-to-Agent)?#

Mecanismo do protocolo A2A#

Modelos de comunicação A2A#

Gestão de tarefas#

Colaboração e negociação de conteúdo#

Exemplo de uso#

O que é MCP (Model Context Protocol)?#

Arquitetura chave do MCP#

Host MCP: “A IA com a qual você está falando”#

Cliente MCP: “O conector”#

Servidor MCP: “O provedor de ferramentas”#

Fontes de dados locais: “Seus próprios arquivos e serviços”#

Serviços remotos: “APIs e ferramentas online”#

Colocando tudo junto#

A2A vs MCP — Comparação#

Como eles trabalham juntos#

Exemplo de fluxo de trabalho#

Conclusão#

Como a infraestrutura base MCP + A2A pode moldar o futuro dos mercados de produtos de agentes#

A mudança da interação humano-computador#

Paradigmas de produtos agenticos e seu impacto no SaaS#

Desafios com limites de autenticação e autorização#