MCP, A2A e WebMCP: o mapa dos protocolos de agente em 2026

Os SDKs do MCP tiveram 97 milhões de downloads num único mês. O WebMCP tem especificação aceita, implementação no Chrome e nenhum agente principal consumindo.

Os dois são chamados de "protocolo de agente" no mesmo parágrafo, em quase todo material sobre o assunto.

São três protocolos, três camadas diferentes e três estágios de maturidade que não se parecem. Este post mapeia o que cada um resolve, em que pé cada um está, e o que nenhum dos três resolve.

Todos os números aqui foram verificados em 28 de agosto de 2026. Esta é a área que envelhece mais rápido de todo o cluster.

A confusão começa porque os três resolvem coisas que soam parecidas e não são.

A frase que organiza tudo cabe numa linha: MCP conecta a ferramenta, A2A conecta o par, WebMCP conecta a página.

Se você quer o passo a passo de conectar um servidor, ele está em MCP na prática. Aqui a pergunta é outra: qual desses protocolos merece atenção agora, e por quê.

Em 9 de dezembro de 2025, a Linux Foundation anunciou a formação da Agentic AI Foundation, com três projetos fundadores doados por três empresas diferentes (Linux Foundation, acesso em 28/08/2026).

Os três somam uso em cerca de 40 mil projetos de código aberto.

A lista de membros platinum é o dado mais eloquente: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft e OpenAI. Cisco, IBM, Oracle e Salesforce participam em outras faixas. São empresas que disputam quase tudo, sentadas na mesma fundação para cuidar da camada de conexão.

O A2A tinha feito o mesmo caminho antes, doado pelo Google à Linux Foundation em meados de 2025.

O que isso muda na prática vale ser dito com clareza: protocolo sob fundação neutra fica menos sujeito a decisão unilateral de fornecedor. Não elimina o risco de mudança, e reduz o risco de uma empresa fechar a especificação porque mudou de estratégia.

Uma observação lateral que fecha um círculo do cluster. O AGENTS.md, um dos três fundadores, é o mesmo arquivo cujo estudo do ETH Zurich apareceu em os quatro pilares do contexto: escrito por humano rende cerca de 4 pontos; gerado por LLM piora o resultado. O padrão virou fundação antes de a pesquisa sobre como preenchê-lo estar madura.

Os números do MCP em março de 2026 explicam por que ele deixou de ser assunto de discussão e virou pressuposto.

São 97 milhões de downloads mensais dos SDKs em março de 2026, contra cerca de 2 milhões no lançamento, e mais de 10 mil servidores ativos entre implantações públicas e corporativas.

O roteiro de 2026, publicado em março pelo mantenedor principal David Soria Parra, aponta quatro frentes: escala de transporte, comunicação entre agentes, maturação de governança e prontidão corporativa.

A segunda frente merece registro, sem virar profecia. Comunicação entre agentes é o território do A2A, e ver isso no roteiro do MCP significa que dois protocolos da mesma fundação avançam para o mesmo espaço. É um fato de 2026. O desfecho não está dado, e quem escrever que um vai absorver o outro está adivinhando.

O A2A resolve um problema que só existe quando há mais de um dono.

Dois agentes dentro do seu sistema, escritos por você, não precisam de protocolo para conversar — precisam de uma chamada de função. O A2A serve quando os agentes são sistemas independentes, com propriedade, ferramentas e fronteiras de confiança próprias.

A versão 1.0 chegou em 2026 como a primeira estável e pronta para produção, com suporte multiprotocolo, multi-inquilino corporativo, fluxos de segurança modernizados e caminho de migração para quem adotou cedo. Hoje o protocolo tem mais de 150 organizações participando, passou de 22 mil estrelas no GitHub e roda em produção dentro do Azure AI Foundry e do Amazon Bedrock AgentCore.

O recurso mais interessante da 1.0 é o menos comentado: os Agent Cards assinados.

Um Agent Card é o cartão de apresentação de um agente — o que ele sabe fazer, como falar com ele, que capacidades expõe. Com assinatura criptográfica, o agente que recebe o cartão consegue verificar que ele foi mesmo emitido pelo dono daquele domínio. Identidade verificável antes de qualquer interação, atravessando fronteira organizacional.

Na prática, o cartão carrega o nome do agente, o endereço em que ele atende, as capacidades que expõe e os requisitos de autenticação. Sem assinatura, qualquer um pode publicar um cartão dizendo ser o agente de faturamento de uma empresa. Com assinatura, o receptor confere contra o domínio antes de mandar qualquer coisa.

Isso responde diretamente ao ASI07 da lista da OWASP, comunicação insegura entre agentes, que descrevi em OWASP Top 10 para agentes. O risco ali é um agente confiar no que outro disse sem verificar. O cartão assinado transforma "confio porque respondeu" em "confio porque a assinatura confere".

<!-- [UNIQUE INSIGHT] -->

Aqui está a parte que a maioria do material sobre protocolos não conta.

A ideia é boa e a inversão é elegante. Hoje, um agente que precisa usar um site tira print da tela e adivinha onde clicar, ou depende de seletores de CSS que quebram na próxima atualização de layout. Com WebMCP, o site entrega ao agente a lista do que dá para fazer ali e os parâmetros exatos de cada ação. O controle inverte: em vez de o agente interpretar a página, a página declara suas capacidades.

Vale entender a arquitetura, na formulação de Patrick Brosset, da Microsoft: o navegador é o intermediário, e "a página nunca fala MCP diretamente". As ferramentas rodam dentro da sessão autenticada do usuário.

Agora o estado real, em 28 de agosto de 2026:

Claude, ChatGPT, Perplexity e Gemini não consomem ferramentas WebMCP. O Google afirma que o Gemini no Chrome será o primeiro.

WebMCP tem servidor e não tem cliente. A especificação existe, o navegador implementa, e não há ninguém do outro lado da linha.

É um efeito de rede ao contrário, e ele se sustenta sozinho: nenhum site publica porque nenhum agente consome, e nenhum agente consome porque nenhum site publica. Alguém precisa mover primeiro, e o candidato anunciado é o Gemini dentro do Chrome — o que faz sentido, porque é o único ator que controla os dois lados.

Registro também um detalhe que já vi neste cluster com outro nome. A API mudou de navigator para document em julho de 2026, e o Chrome 150 depreca a localização antiga enquanto ainda a serve. Em observabilidade de agente foi o gen_ai.system virando gen_ai.provider.name. Especificação em movimento quebra código, e as duas vezes o sinal foi o mesmo: quem instrumentou cedo pagou uma renomeação.

Os três transportam chamadas. Nenhum transporta política.

Em 1º de julho de 2026, Richard Kang e Yudho Diponegoro publicaram uma análise das lacunas de governança em protocolos de interoperabilidade de agentes (arXiv 2606.31498, acesso em 28/08/2026), examinando MCP, A2A e ACP.

O terceiro protocolo do estudo, o ACP, aparece pouco em português e vale uma linha. Ele é mais uma tentativa de padronizar comunicação entre agentes, com adesão bem menor que a do A2A. Se você está escolhendo hoje, o A2A é a aposta com mais massa crítica. O ACP entra aqui porque o estudo o avaliou junto, e porque as lacunas apontadas valem para os três.

Cinco lacunas:

Os exemplos concretos que os autores citam como não codificáveis são específicos: limiar de votação, hierarquia de permissão, trilha de auditoria e mecanismo de consenso.

A consequência prática é direta e vale para quem está montando sistema com vários agentes agora. O protocolo garante que a mensagem chega e, no caso do A2A, que ela veio de quem diz ter vindo. Ele não garante que o agente tinha o direito de pedir aquilo.

Isso conversa com o argumento de guardrails: trava estrutural vale mais que instrução, e a trava precisa existir em algum lugar. Como o protocolo não a carrega, ela é código seu. Hierarquia de permissão entre agentes, hoje, se constrói fora da camada de protocolo.

Duas renomeações apareceram neste post. A do WebMCP, de navigator para document, em julho de 2026. E a do OpenTelemetry, que virou gen_ai.provider.name.

O padrão é claro. Especificação nova muda nome. Quem adota cedo paga a conta.

Isso não é motivo para esperar. É motivo para adotar de um jeito específico.

Isole o contato com o protocolo numa camada só. Uma função que fala com o servidor MCP. Um módulo que monta o Agent Card. Um arquivo que registra as ferramentas WebMCP. Quando o nome mudar, você edita um lugar.

Fixe a versão. Protocolo em desenvolvimento não deve ser consumido pela última versão automaticamente. Fixe, leia o changelog, suba quando quiser.

Guarde a data da decisão. Escreva no código por que aquela versão foi escolhida e quando. Daqui a seis meses, alguém vai perguntar, e a resposta economiza uma tarde.

Prefira o protocolo que tem fundação. Não é garantia contra mudança. É garantia de que a mudança passa por processo público, com aviso, em vez de aparecer num release note.

Nada disso é específico de agente. É o mesmo cuidado que se toma com qualquer dependência anterior à versão 1.0, e a única novidade é que muita gente está adotando esses protocolos sem tratá-los como o que são.

O critério é o problema, e não a novidade.

A linha do WebMCP merece uma recomendação explícita sobre tempo. Implementar hoje é apostar num consumidor que ainda não existe. Faz sentido para quem tem equipe sobrando e quer estar pronto quando o Gemini no Chrome ligar a chave, e não faz para quem tem lista de prioridades.

A linha dos agentes internos merece a mesma franqueza. Adotar A2A entre dois componentes do mesmo sistema, com o mesmo dono e o mesmo deploy, adiciona serialização, descoberta e verificação de identidade para resolver o que uma chamada direta já resolvia. O critério de quando delegar a um subagente vale aqui: a fronteira precisa ser real para o protocolo valer.

<!-- [PERSONAL EXPERIENCE] -->

Fui conferir antes de escrever esta seção, e a resposta é honestamente pequena.

O projeto não tem arquivo de configuração de MCP. Nenhum servidor declarado, nenhuma integração de protocolo entre o agente e as ferramentas de publicação. As ferramentas que fazem o trabalho — ler e escrever arquivo, rodar o build, gerar as capas, montar o schema — são locais e nativas.

Existe um uso real, e é pontual: uma conexão de automação de navegador, usada quando precisei conferir indexação no Search Console. Isso é MCP fazendo o que ele faz de melhor, dar ao agente uma capacidade que ele não tinha. Fora disso, protocolo nenhum.

O motivo não é ideológico. É que só existe um agente aqui, e as ferramentas moram na mesma máquina que ele. As duas condições que justificam A2A — mais de um dono, fronteira de confiança real — não se aplicam a uma operação de uma pessoa só.

Sobre WebMCP a situação tem graça própria, porque este blog é um site. Em tese, eu poderia expor funções para agentes: buscar posts por tema, listar o que saiu numa data, devolver o texto de um artigo. Em fevereiro isso teria parecido visionário.

Hoje, com a informação da seção anterior, seria trabalho para zero consumidores. Fica anotado como decisão consciente e datada: reavaliar quando algum agente principal passar a consumir.

Se este blog crescesse para uma redação com vários autores e agentes de donos diferentes, a conversa mudaria. Não é o caso, e adotar protocolo antes de existir a fronteira que ele resolve é a forma mais elegante de adicionar complexidade sem comprar nada.

Deixo anotados os três gatilhos que mudariam a decisão, porque decisão sem gatilho vira dogma:

• Uma ferramenta útil só existir como servidor MCP. Aí o protocolo entra por necessidade, e não por arquitetura.
• Outra pessoa passar a operar um agente sobre o mesmo repositório. Duas fronteiras de confiança justificam identidade verificável.
• Algum agente principal começar a consumir WebMCP. Aí expor funções do site deixa de ser aposta.

Nenhum dos três aconteceu até 28 de agosto de 2026. Quando algum acontecer, volto aqui e atualizo esta seção com a data.

Qual a diferença entre MCP e A2A?

MCP conecta um agente a ferramentas, dados e sistemas: é a camada de "o que eu consigo chamar". A2A conecta agentes independentes entre si, atravessando fronteiras de confiança e organizações: é a camada de "com quem eu converso". Eles não competem; um projeto pode usar os dois. Na prática, MCP é necessário em quase todo agente útil, e A2A só passa a valer quando existe mais de um dono envolvido.

O que é WebMCP?

É uma interface de navegador que permite a uma página expor funções tipadas para agentes de IA, em vez de o agente tirar print e adivinhar onde clicar. O site declara o que sabe fazer e quais parâmetros cada ação exige, e o navegador atua como intermediário. A especificação foi aceita pelo W3C em setembro de 2025 e o Chrome roda um teste público de origem desde a versão 149.

Preciso dos três?

Quase certamente não. A maioria dos projetos precisa de MCP e mais nada. A2A entra quando agentes de organizações diferentes colaboram. WebMCP faz sentido para quem publica um site que quer ser operado por agentes, e hoje isso é uma aposta, porque nenhum agente principal consome essas ferramentas ainda.

MCP ainda é da Anthropic?

Não. A Anthropic doou o MCP à Agentic AI Foundation, criada pela Linux Foundation em 9 de dezembro de 2025, junto com o goose, da Block, e o AGENTS.md, da OpenAI. A fundação tem oito membros platinum, incluindo AWS, Google, Microsoft e OpenAI. Na prática, isso reduz o risco de uma única empresa mudar a especificação de forma unilateral.

E se eu já adotei uma versão antiga?

Leia o changelog antes de subir de versão, e migre em um lugar só. Os dois casos citados neste post tiveram caminho de saída: o A2A publicou caminho de migração junto com a versão 1.0, e o Chrome depreca a localização antiga da API do WebMCP enquanto ainda a serve durante o teste de origem. Quem isolou o contato com o protocolo numa camada única paga a migração em horas. Quem espalhou chamadas pelo código paga em dias.

Vale implementar WebMCP no meu site agora?

Para a maioria, ainda não. A especificação está em teste de origem no Chrome, mudou de local de API em julho de 2026, e nenhum dos agentes principais consome as ferramentas publicadas. Implementar hoje significa construir para um consumidor que não existe. Faz sentido se você tem folga de equipe e quer estar pronto quando o Gemini no Chrome começar a consumir, que é o primeiro movimento anunciado.

• MCP conecta a ferramenta, A2A conecta o par, WebMCP conecta a página. Camadas diferentes, não concorrentes.
• Os três estão sob a Agentic AI Foundation desde dezembro de 2025, com oito membros platinum que competem entre si.
• MCP virou infraestrutura: 97 milhões de downloads mensais e mais de 10 mil servidores.
• A2A vale pela identidade verificável — Agent Cards assinados — e só quando há mais de um dono.
• WebMCP tem servidor e não tem cliente. Boa ideia, sem consumidor.
• Nenhum dos três expressa governança. Permissão, auditoria e limite de recurso são código seu.

O próximo post do cluster pega o fio que o A2A deixou aberto: identidade de agente, o privilégio que ninguém revoga. O mapa das cinco camadas continua no pilar sobre harness engineering.