MCP, WebMCP e A2A: que protocolo escolher para os teus agentes IA em 2026

Pela equipa da Kiwop · Agência Digital especializada em Desenvolvimento de Software e Inteligência Artificial aplicada para clientes globais na Europa e EUA · Publicado a 19 de abril de 2026 · Última atualização: 19 de abril de 2026

TL;DR — A abril de 2026 convivem três protocolos chave para agentes IA. MCP (Model Context Protocol) liga um agente com as suas ferramentas e dados; é o padrão de facto, doado à Linux Foundation. WebMCP é a variante browser para que os sites exponham ações a agentes; continua emergente. A2A (Agent-to-Agent) liga agentes entre si; v1.0 em produção com mais de 150 organizações. Usa MCP para tools, A2A para orquestrar e WebMCP para o teu site.

Cada semana recebemos a mesma pergunta de comités de direção e equipas de produto: "Estamos a construir um agente IA, que protocolo usamos?". A resposta correta já não é "MCP e ponto final" — era em 2025, mas 2026 trouxe uma constelação de padrões que se complementam mais do que competem. O interessante não é qual ganha: é qual resolve cada problema.

Este artigo é a comparação técnica que nos teria poupado semanas de investigação há seis meses. Está baseada na nossa experiência real a construir assistentes pessoais com Claude Code e MCP, no trabalho interno sobre Nexo (o nosso SaaS de workspace em desenvolvimento), e nas fontes oficiais mais recentes publicadas pela Anthropic, Google, Cloudflare, Vercel, Linux Foundation e o próprio W3C. Se procuras uma resposta binária, não a terás aqui. Se procuras critério de decisão, continua a ler.

Porque 2026 é o ano dos protocolos agentes IA

2023 foi o ano do prompt. 2024 foi o ano da ferramenta (tool use). 2025 foi o ano do agente. E 2026 está a ser, sem dúvida, o ano dos protocolos. A razão é simples: quando há um único agente a falar com uma única API, qualquer contrato ad hoc funciona. Quando tens dezenas de agentes, dúzias de modelos de distintos fornecedores, centenas de ferramentas internas e externas, e clientes que querem ligar os seus próprios agentes aos teus, o caos come o produto.

A explosão tem sido brutal. A Anthropic reporta mais de 10.000 servidores MCP públicos ativos e 97 milhões de descargas mensais de SDK entre Python e TypeScript segundo a nota oficial de doação de MCP à Linux Foundation. A2A, por sua vez, passou de uma proposta da Google em abril de 2025 a contar com mais de 150 organizações e estar sob a égide da Linux Foundation no início de 2026. A 9 de dezembro de 2025 formalizou-se a Agentic AI Foundation (AAIF) sob a Linux Foundation, com Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare e Bloomberg como membros platina — um movimento coberto pela TechCrunch que marca o fim da era de protocolos proprietários.

A fotografia a abril de 2026 é a seguinte. Há três protocolos que qualquer equipa técnica precisa de entender: MCP, WebMCP e A2A. Há um quarto, ACP (Agent Communication Protocol) da IBM, que conceptualmente se sobrepõe com A2A e cuja adoção a dia de hoje é consideravelmente menor. E há uma plêiade de iniciativas adjacentes — AGENTS.md, Open Responses, ANP, LLMFeed — que orbitam sem ainda alcançar a mesma massa crítica. Focar-nos-emos nos três que importam para decisões de arquitetura reais.

A fragmentação é um problema real. Como se aponta na investigação académica do arXiv sobre protocolos de interoperabilidade de agentes, cada protocolo resolve uma camada distinta do stack: o problema não é escolher um, é entender em que camada opera cada um e combiná-los sem criar acoplamentos desnecessários. Essa é a tese que vamos desenvolver.

MCP — Model Context Protocol (Anthropic, 2024)

MCP é, a abril de 2026, o padrão de facto para ligar um agente IA a ferramentas externas. Foi publicado pela Anthropic em novembro de 2024 como protocolo aberto, e no seu primeiro ano percorreu o caminho que outros padrões levaram uma década a percorrer: de proposta individual a infraestrutura partilhada da indústria.

O que é MCP conceptualmente

MCP define um contrato entre duas partes: um cliente MCP (geralmente o agente ou o host do modelo) e um servidor MCP (geralmente um adaptador para um serviço externo: Gmail, GitHub, uma base de dados, um sistema interno). O cliente descobre que ferramentas oferece o servidor, lê o seu esquema, e invoca-as com parâmetros tipados. A comunicação usa JSON-RPC 2.0 sobre um transporte.

O protocolo não cobre apenas ferramentas (tools): define também resources (conteúdo legível estaticamente, como ficheiros ou registos), prompts (templates reutilizáveis) e — desde a especificação de 25 de novembro de 2025 — operações assíncronas, stateless servers, server identity e extensões oficiais segundo a especificação oficial. Esta evolução é a que permitiu a MCP passar de "ligar um cliente local" a "alimentar infraestrutura de agentes em produção".

Transportes: stdio e Streamable HTTP

MCP suporta dois transportes oficiais segundo a documentação de transportes do spec:

• stdio: o cliente arranca o servidor como um subprocesso local e comunica-se por entrada/saída padrão. Ideal para execuções locais, CLI e assistentes pessoais.
• Streamable HTTP: o servidor vive como processo independente e expõe um único endpoint HTTP que aceita POST e GET. Pode usar Server-Sent Events para streaming. É o padrão de facto para servidores remotos em 2026, e substitui o antigo transporte HTTP+SSE.

A regra rápida: stdio para assistentes pessoais numa máquina, Streamable HTTP para serviços partilhados em produção.

Servidores disponíveis e ecossistema

A abril de 2026, o ecossistema MCP cobre praticamente qualquer serviço empresarial relevante: Gmail, Google Calendar, Google Drive, Slack, Linear, GitHub, Notion, Jira, Confluence, Salesforce, HubSpot, Stripe, PostgreSQL, Snowflake, BigQuery e dezenas mais. A adoção cruza fronteiras de fornecedor: a OpenAI suportou-o nativamente no ChatGPT em março de 2025, a Microsoft integrou-o no Copilot, a Google suporta-o no Gemini, e editores como Cursor, Windsurf e VS Code falam MCP de forma nativa.

Casos de uso ótimos

MCP brilha quando há um agente que precisa de acesso a muitas fontes heterogéneas: um assistente pessoal que lê o teu correio e o teu calendário, um copiloto de desenvolvimento que consulta o teu código e os teus tickets, um agente de vendas que cruza dados de CRM e faturação. Em todos esses casos, o padrão é o mesmo: o agente invoca ferramentas tipadas em servidores que falam com sistemas concretos.

Limitações

MCP não é a ferramenta correta quando o tráfego é agente↔agente (aí entra A2A), quando o consumidor é um browser e não um processo com credenciais OAuth pré-instaladas (aí entra WebMCP), nem quando a operação requer streams binários massivos ou latências submilissegundo (aí entram APIs específicas). E embora a adoção seja enorme, a segurança continua a ser uma área de trabalho ativa: há literatura crescente sobre tool poisoning, prompt injection através de descrições de ferramentas, e permissões difíceis de auditar. Qualquer agente MCP em produção precisa de uma camada de sandboxing e confirmação que o protocolo não impõe por si mesmo.

WebMCP — o MCP para a web (2025-2026)

WebMCP é a aposta da Google e da Microsoft para transpor a filosofia MCP ao browser e à própria web. Não é uma extensão de MCP: é um padrão paralelo, coordenado dentro do W3C Web Machine Learning Community Group, que adapta o contrato cliente-servidor ao ambiente específico do browser. Já cobrimos a proposta inicial em WebMCP: o teu site preparado para agentes IA; aqui focamo-nos em como se posiciona face a MCP e A2A.

Porquê WebMCP e não simplesmente MCP sobre HTTP

À primeira vista soa redundante: se MCP já tem transporte Streamable HTTP, para quê outro padrão? O ecossistema WebMCP está em early-preview a abril de 2026, mas a razão de existir vai além da imaturidade. A resposta técnica é que o browser é um ambiente radicalmente distinto de um servidor. No browser:

• A autenticação é gerida pelo utilizador, não pelo agente (a cookie de sessão vive no browser, não viaja com o agente).
• As ações têm de ser visíveis e supervisáveis pelo humano (não há espaço para automatismos opacos).
• A superfície exposta é a do site visitado, não um endpoint dedicado.
• A descoberta ocorre quando o utilizador navega para a página, não através de um registo global.

WebMCP resolve exatamente essas diferenças. Segundo a documentação oficial da Cloudflare Browser Run sobre WebMCP, o site expõe um conjunto de tools — por exemplo searchFlights() ou bookTicket() — com parâmetros tipados. Um agente que navega a página pode descobrir essas tools, ler os seus esquemas e invocá-las diretamente sem simular clicks nem fazer scraping do DOM.

Implementação: Cloudflare e Vercel

Os dois fornecedores que mais rapidamente mexeram foram a Cloudflare e a Vercel, embora com abordagens distintas.

• A Cloudflare acrescentou suporte WebMCP ao seu produto Browser Run (antes Browser Rendering) a 15 de abril de 2026, segundo o seu changelog oficial. A integração permite que um agente IA ligue o seu cliente MCP contra Browser Run via o endpoint CDP e descubra tools expostas por qualquer site que implemente WebMCP — mesmo quando esse site não controla a infraestrutura.
• A Vercel orientou o seu produto para o deploy de servidores MCP sobre a sua plataforma Functions, aproveitando o Fluid Compute para otimizar padrões de uso irregulares típicos de agentes. A documentação oficial da Vercel MCP descreve como montar endpoints Streamable HTTP com OAuth built-in, e o seu AI SDK inclui cliente MCP experimental. Embora a Vercel seja mais MCP clássico do que WebMCP puro, é o fornecedor de referência quando o teu backend já vive em Next.js.

Casos de uso ótimos

WebMCP é a resposta correta quando o teu produto é um site público e queres que os agentes IA o usem bem: e-commerce (pesquisa, filtros, carrinho, checkout), SaaS com formulários complexos (configuradores, orçamentos), marketplaces, sistemas de reservas. Todo o caso em que um utilizador humano usaria botões e formulários e queres que um agente faça o mesmo com menos fricção.

Estado de adoção a abril de 2026

Aqui é preciso ser honesto: WebMCP é emergente, não maduro. Chrome suporta-o de forma experimental em Canary, Cloudflare tem produção parcial, e a cobertura da AB Magency sobre a "guerra de formatos agentic" recolhe que WebMCP compete simultaneamente com propostas como Markdown for Agents da Cloudflare (lançada a 12 de fevereiro de 2026). Ambas coexistem; nenhuma ganhou. Para uma equipa que precisa de decidir hoje, WebMCP é uma aposta de futuro razoável para sites com tráfego agente previsível, mas não é um padrão sobre o qual apostar toda a arquitetura.

A2A — Agent-to-Agent protocol (2026)

Se MCP liga um agente com as suas ferramentas, A2A liga agentes entre si e, a abril de 2026, é o padrão horizontal de referência. É a diferença entre "um trabalhador usa as suas ferramentas" e "um trabalhador delega tarefa a outro trabalhador". Não é uma distinção académica: resolve problemas reais que MCP não pode resolver.

Origem e estado atual

A2A foi anunciado pela Google no Google Cloud Next 2025 a 9 de abril de 2025, com mais de 50 parceiros de lançamento (Accenture, Atlassian, Box, Cohere, Deloitte, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UiPath, entre outros). Em junho de 2025 a Google doou-o à Linux Foundation. Em março de 2026 publicou-se A2A v1.0, a versão que a comunidade considera apta para produção. A documentação oficial em a2a-protocol.org descreve o modelo em detalhe; o anúncio de upgrade do Google Cloud Blog documenta as melhorias da v1.0.

Arquitetura: Agent Cards e descoberta

O conceito central de A2A é a Agent Card: um documento JSON que descreve o que sabe fazer um agente, que skills expõe, que autenticação requer e onde contactá-lo. Os agentes descobrem-se lendo as Agent Cards de outros agentes, tal como os serviços web se descobrem por OpenAPI. Em v1.0 as Agent Cards levam assinatura criptográfica (Signed Agent Cards), o que permite verificar que uma card foi emitida pelo domínio proprietário do agente — uma melhoria importante contra impersonação.

O transporte é JSON-RPC 2.0 sobre HTTP, Server-Sent Events, ou gRPC, com autenticação via API keys, HTTP auth, OAuth 2.0/OIDC e mutual TLS. Ou seja: as mesmas peças que qualquer backend empresarial usa há uma década, sem reinventar nada.

Casos de uso ótimos

A2A é a resposta correta quando há vários agentes especializados que precisam de colaborar: um agente orquestrador que delega "procurar um voo" a um agente de viagens, "reservar um hotel" a um agente de hotéis, e "pagar" a um agente de pagamentos. Cada agente especializado tem as suas próprias ferramentas (MCP internamente) e oferece a sua Agent Card ao exterior para ser orquestrado. Cenários típicos: purchasing concierges multi-fornecedor, workflows multi-departamento em grandes empresas, marketplaces de agentes.

Diferença fundamental com MCP

A chave, bem resumida pela IBM no seu artigo sobre A2A, é que MCP é vertical (agente↔tool) e A2A é horizontal (agente↔agente). Ambos são complementares. Um agente A2A pode internamente usar MCP para aceder aos seus dados. Um agente MCP pode não precisar de A2A nunca se for um único agente. A decisão não é "MCP ou A2A"; é "preciso de um, do outro, ou de ambos".

Limitações e maturidade

A2A v1.0 é recente. Embora haja deploys de produção em Microsoft, AWS, Salesforce, SAP e ServiceNow segundo a cobertura da Stellagent, o ecossistema de agentes interoperáveis é ainda pequeno comparado com o de ferramentas MCP. Construir com A2A hoje implica construir muitas das peças que MCP já tem maduras: bibliotecas, gateways, debuggers, observabilidade. Se o teu problema é "um agente com muitas tools", A2A acrescenta complexidade sem resolver nada novo.

Tabela comparativa: MCP vs WebMCP vs A2A

A tabela é densa de propósito. Se tivéssemos de a resumir numa frase: MCP manda dentro do agente, A2A manda entre agentes, WebMCP manda no browser. Qualquer decisão arquitetónica começa por identificar onde estás e trabalhar a partir daí.

Exemplo real 1: PA da Kiwop usa MCP stdio

O nosso PA (Personal Assistant) — o assistente pessoal IA que construímos na Kiwop após o corte OAuth da Anthropic a 4 de abril de 2026, documentado em detalhe em de OpenClaw a PA com Claude Code e MCP — é um caso de escola do uso ótimo de MCP stdio.

A arquitetura numa frase

Claude Code corre numa máquina local (macOS, com launchd como gestor de processos). Precisa de acesso a Gmail, Google Calendar, Google Drive e Slack. Para cada um desses quatro serviços, temos um servidor MCP local arrancado como subprocesso da sessão. O cliente MCP embebido no Claude Code lança os servidores por stdio, descobre as suas tools, e invoca-as quando é preciso.

Porquê stdio e não Streamable HTTP

A tentação era implementar os servidores MCP num endpoint HTTP e que o Claude Code se ligasse por rede. Descartámo-la por três razões:

1. Credenciais: os OAuth tokens de Gmail, Calendar, Drive e Slack vivem no Keychain do macOS. Expor esses tokens por rede implicaria tunneling, rotação, e um modelo de segredos que não queríamos.
2. Latência: stdio é processo local com pipe UNIX. Cada invocação é submilissegundo. Um endpoint HTTP acrescenta tempo de rede sem ganho funcional.
3. Simplicidade operacional: no dia em que algo se parte, inspecionar um processo local é infinitamente mais fácil do que depurar um serviço remoto.

A decisão encaixa com a lógica geral que descrevemos em LLMOps: gerir modelos de linguagem em produção — manter perto o que pode estar perto reduz superfície de falha. Essa é a filosofia que vamos refletir também no próximo post sobre padrões e antipadrões de agentes IA em produção.

O que NÃO tocámos

Nem WebMCP nem A2A. O PA é um único agente (Claude Code) com muitas ferramentas, operado por uma única pessoa. Introduzir A2A seria sobre-engenharia pura: não há outro agente com quem se coordenar. Introduzir WebMCP não se aplica: não há um browser pelo meio, e os serviços MCP já cobrem tudo o que precisamos.

Isto é importante: um bom desenho é tão valioso pelo que deixa de fora como pelo que inclui. Cada protocolo acrescentado é código a manter, superfície de ataque, e dependência de políticas de fornecedor.

Exemplo real 2: Nexo (o nosso SaaS) planeia WebMCP para clientes

Nexo é o SaaS interno que estamos a construir na Kiwop — um workspace colaborativo com capacidades de agentes integrados. Sem entrar em detalhes de produto (será lançado oficialmente mais à frente), podemos sim contar a decisão arquitetónica sobre protocolos, porque ilustra perfeitamente o dilema que enfrentarão a maioria dos SaaS nos próximos 12-18 meses.

O problema: clientes que querem ligar os seus próprios agentes

Os clientes beta pediam-nos duas coisas muito distintas:

1. "Queremos que os nossos próprios agentes (Claude, GPT, agentes internos do cliente) acedam aos dados do seu workspace em Nexo."
2. "Queremos que os vossos agentes internos em Nexo possam colaborar com os agentes que a minha empresa já tem."

São dois problemas de protocolos completamente distintos.

Decisão: WebMCP (e MCP remoto) para o primeiro, A2A para o segundo

Para o primeiro problema (clientes a ligar agentes externos aos seus dados em Nexo) decidimos expor um servidor MCP Streamable HTTP por tenant e, em paralelo, preparar endpoints WebMCP para que, quando os utilizadores naveguem a UI de Nexo a partir de um browser com agente, esse agente possa descobrir as ações disponíveis sem scrapear o DOM. As tools expostas são as mesmas em ambos os transportes; muda quem as consome e como se autenticam. Encaixa com o que já recomendamos a clientes no nosso serviço de integração de LLMs.

Para o segundo problema (orquestração de agentes de cliente com os nossos agentes) apostamos em A2A. Publicaremos Agent Cards assinadas para cada capability interna (classify-document, summarize-meeting, draft-email), o cliente poderá descobri-las a partir do seu agente orquestrador, e o tráfego será JSON-RPC sobre HTTP com OAuth 2.0. A vantagem chave de A2A face a "faço outra API REST" é que o cliente não tem de aprender a nossa API: o seu agente descobre, lê a card, e opera.

O que NÃO escolhemos e porquê

Descartámos montar tudo sobre MCP puro embora tecnicamente seja possível. A razão é que MCP está otimizado para agente↔tool: se um cliente quer delegar a Nexo com um agente próprio e obter resultados complexos (multi-step, com estados intermédios, com raciocínios expostos), A2A encaixa melhor. MCP não está pensado para conversas agente↔agente com memória partilhada.

Descartámos também começar com A2A para tudo, já que para o caso "cliente que quer ler/escrever dados do seu workspace com Claude" um servidor MCP é a rota curta e padrão, com o maior ecossistema de clientes por detrás.

A lição mais ampla, para qualquer SaaS que esteja a pensar como se abrir a agentes: não é uma decisão binária, é uma decisão por caso de uso. Expor dados a um único agente cliente → MCP remoto. Expor uma web pública a agentes que a visitam → WebMCP. Interoperar com agentes de clientes como iguais → A2A.

Quando NÃO usar MCP (nem WebMCP nem A2A)

Um capítulo que falta em muitos artigos. Os protocolos de agentes são muito bons para o seu domínio e muito maus fora dele. Alguns sinais de que NÃO deverias meter MCP, WebMCP nem A2A na tua arquitetura:

• Latência extrema. Se a operação requer resposta submilissegundo (trading de alta frequência, controlo industrial, videojogos), a sobrecarga de JSON-RPC, o handshake, a descrição de tools e o round-trip do modelo matam qualquer protocolo de agentes. Usa APIs binárias específicas.
• Streams binários massivos. Transcodificação de vídeo, processamento de imagens em volume, streaming de áudio em tempo real. MCP pode invocar o job, mas não é o canal por onde viajam os bytes. Conserva os teus pipelines específicos.
• Processos batch longos sem agente. Se o teu caso é "cron job processa um CSV todas as noites", um agente IA com MCP é artilharia contra pardais. Um script e um scheduler continuam a ser a resposta correta.
• Determinismo estrito. Operações bancárias, transações críticas, logs de auditoria. Um agente com tools pode ficar no loop, mas o motor transacional deve ser determinista, com retentativas documentadas e sem margem para "o modelo escolheu outra tool".
• Compliance regulado com auditoria exaustiva. Se cada chamada deve deixar rasto legalmente reproduzível, precisas de uma camada por baixo dos protocolos de agentes — não por cima — que garanta esse registo. Pode-se fazer, mas acrescentar um agente IA não simplifica o compliance; complica-o.

Relacionado: em setores regulados (sanitário, legal, financeiro), qualquer arquitetura de agentes IA requer passar por uma fase de consultoria de inteligência artificial para entender o que é permitido antes de escolher protocolo. Escolher protocolo sem passar por aí é o antipadrão clássico.

Interoperabilidade: podes combinar os três?

Sim, e de facto é provável que o faças. O padrão mais limpo em abril de 2026 combina os três protocolos num stack coerente.

O diagrama conceptual:

1. Um agente orquestrador (nível mais alto, fala A2A para fora).
2. Quando precisa de usar uma ferramenta interna (ler uma base de dados, chamar uma API empresarial) → MCP.
3. Quando precisa de delegar uma subtarefa complexa a outro agente especializado → A2A para esse agente.
4. Quando precisa de atuar sobre um site externo que não expõe API própria mas sim WebMCP → cliente WebMCP via browser.

O agente recetor em A2A, por sua vez, internamente usa MCP para as suas próprias tools. E se o agente recetor é um SaaS público com frontend, provavelmente expõe também uma superfície WebMCP para utilizadores humanos com agentes. O sistema é recursivo e componível: cada agente é um cliente dos três protocolos e (potencialmente) um servidor de dois (MCP e A2A).

Esta composição é precisamente o que descrevem fontes como o mapa de protocolos da Digital Applied ou o guia da WorkOS sobre MCP/ACP/A2A: os protocolos não competem porque resolvem camadas distintas. Competem com as suas alternativas na mesma camada (WebMCP vs Markdown for Agents; A2A vs ACP), não entre si.

Uma nuance: evita a sobre-orquestração

Antes de meter os três protocolos num sistema, pergunta-te se os precisas. A maioria das aplicações IA em produção a dia de hoje precisam apenas de MCP. Uma minoria grande precisa de MCP + WebMCP (SaaS com frontend público). Uma minoria pequena mas crescente precisa de MCP + A2A (ecossistemas multi-agente). O caso triplo é real mas raro. Se não podes justificar porque cada camada resolve um problema distinto, provavelmente sobra alguma.

Tabela: quando usar cada um

Tabela: maturidade de adoção a abril de 2026

Roadmap e adoção em 2026

O que está em cada etapa segundo fontes oficiais a abril de 2026:

• MCP: especificação estável de 25 de novembro de 2025 com operações assíncronas e servers stateless; próximo marco relevante, o MCP Dev Summit Europe anunciado para 17-18 de setembro de 2026 em Amsterdam. Sinais a observar: consolidação do transporte Streamable HTTP como default remoto, retirada progressiva do SSE legacy, estandardização de padrões de segurança para tool poisoning.
• A2A: v1.0 publicada em março de 2026 com Signed Agent Cards e extensão formal AP2. Sinais a observar: crescimento do registo público de Agent Cards, aparição de gateways A2A (equivalentes a API gateways tradicionais), integração nativa com os grandes orquestradores (LangGraph, CrewAI, AutoGen).
• WebMCP: programa early preview aberto, implementação parcial em Cloudflare, suporte limitado em Chrome Canary. Sinais a observar: aceitação do rascunho no W3C, decisão do Chromium Stable sobre suporte por defeito, posicionamento definitivo face a Markdown for Agents.
• Padrões adjacentes: AGENTS.md (proposto pela OpenAI, sob AAIF), Open Responses (especificação aberta da OpenAI para loops de agentes interoperáveis, reportada pela InfoQ em fevereiro de 2026), e Skills (contribuídos por Block/Anthropic). Nenhum compete com MCP/WebMCP/A2A diretamente, mas sim resolve peças complementares: descrição de repos, interoperabilidade de loops, bundling de prompts.

A previsão menos arriscada para os próximos 6-12 meses é que MCP se consolide como commodity, A2A alcance a sua primeira grande onda de deploys B2B, e WebMCP continue a ser um terreno em disputa até que Chrome Stable decida suportá-lo ou não. No caso de decidir não suportá-lo, a proposta pode morrer ou migrar para uma solução alternativa (Markdown for Agents ou outra).

Perguntas frequentes

MCP é só da Anthropic?

Não desde dezembro de 2025. A Anthropic doou MCP à recém-criada Agentic AI Foundation sob a Linux Foundation, com Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare e Bloomberg como membros platina. Hoje MCP tem governança comunitária. A Anthropic continua a contribuir fortemente para o desenvolvimento mas já não é o único decisor.

WebMCP substitui a minha REST API?

Não. WebMCP expõe uma superfície pensada para agentes que operam a partir de browsers. A tua REST API continua a ser a via correta para integrações backend-backend, apps móveis, e clientes autenticados com credenciais próprias. WebMCP acrescenta uma camada orientada ao agente do utilizador, não a substitui.

A2A está pronto para produção a abril de 2026?

Sim para casos padrão. A v1.0 publicada em março de 2026 inclui Signed Agent Cards e considera-se apta para produção. Há deploys em Microsoft, AWS, Salesforce, SAP e ServiceNow. No entanto, o ecossistema de bibliotecas e tooling está menos maduro que o de MCP — espera dedicar mais engenharia própria a gateways, observabilidade e gestão de Agent Cards.

Que SDK usar para começar com MCP?

Os SDKs oficiais em Python e TypeScript cobrem a maioria dos casos. Para construir servidores no ecossistema Anthropic, o SDK TypeScript oficial é a rota recomendada. Para scripting e servidores locais, o SDK Python é o padrão. Ambos são mantidos pela Anthropic com suporte oficial.

Posso usar MCP com modelos que não são da Anthropic?

Sim. Desde março de 2025, ChatGPT suporta MCP nativamente; Copilot e Gemini também. Os servidores MCP são agnósticos ao modelo: qualquer cliente que fale o protocolo pode consumi-los. Esta é a razão principal pela qual MCP ganhou — a portabilidade entre fornecedores é real, não marketing.

WebMCP é o mesmo que Markdown for Agents da Cloudflare?

Não. São duas propostas competidoras com filosofias distintas. WebMCP expõe ações tipadas que o agente invoca; Markdown for Agents expõe uma representação markdown estruturada do site para que o agente a interprete. A abril de 2026 ambas coexistem e nenhuma ganhou. Se queres cobrir ambos os flancos, a Cloudflare documenta como implementar suporte paralelo.

Qual é a diferença real entre A2A e ACP?

Conceptualmente resolvem o mesmo problema: comunicação horizontal entre agentes. A2A é impulsionado pela Google e tem muito mais tração (mais de 150 organizações, Linux Foundation, v1.0 produção). ACP é impulsionado pela IBM (BeeAI) com adoção mais limitada. Tecnicamente ACP usa convenções HTTP mais diretas; A2A usa JSON-RPC com Agent Cards assinadas. Se hoje começas do zero, A2A tem melhor relação valor/risco por ecossistema.

Preciso dos três protocolos no meu projeto?

Quase nunca. A maioria dos projetos IA começam apenas com MCP. Um SaaS com frontend público acrescenta WebMCP quando o tráfego agente justifica o investimento. Um ecossistema com múltiplos agentes a interoperar acrescenta A2A. O erro comum é meter os três desde o dia um sem caso de negócio claro; o padrão saudável é começar com MCP e acrescentar o resto apenas quando há problema real a resolver.

Conclusão: escolhe por camada, não por marca

A pergunta correta em 2026 não é "que protocolo é melhor?" mas sim "que camada estou a resolver?". MCP manda dentro do agente, no vínculo agente↔tool. A2A manda entre agentes, no vínculo horizontal. WebMCP manda na fronteira entre a tua web pública e os agentes que a visitam. São três camadas distintas; não competem, compõem-se.

A lição operacional, após construir o PA sobre MCP stdio e desenhar Nexo sobre MCP remoto + A2A + WebMCP, é que o custo de escolher mal um protocolo é enorme. Cada protocolo traz consigo um modelo mental, um conjunto de bibliotecas, uma curva de adoção de clientes e um compromisso de manutenção a longo prazo. Mas também é verdade — e isto é talvez o mais importante — que a portabilidade entre camadas nunca foi maior. Um servidor MCP bem desenhado consome-se a partir de Claude, ChatGPT, Copilot, Gemini e Cursor sem mudanças. Um agente A2A bem desenhado é visível a partir de qualquer orquestrador que fale o protocolo. Um site com WebMCP responde a qualquer agente que o visite. O investimento em protocolos abertos amortiza-se rapidamente.

Na Kiwop — Agência Digital especializada em Desenvolvimento de Software e Inteligência Artificial aplicada para clientes globais na Europa e EUA — levamos dois anos a construir sobre LLMs em produção e desde o início de 2025 sobre MCP. Se a tua equipa está a decidir hoje como abrir a vossa plataforma a agentes IA ou como orquestrar um sistema multi-agente, podemos ajudar-vos a escolher a arquitetura correta sem sobre-engenharia. Dá uma vista de olhos aos nossos serviços de desenvolvimento de agentes IA, consultoria de inteligência artificial e integração de LLMs — ou escreve-nos e sentamo-nos.

E se te interessou o percurso técnico, segue o fio com os outros posts do cluster: de OpenClaw a PA com Claude Code e MCP, constrói o teu PA com Claude Code e MCP, agentes IA em produção: padrões e antipadrões 2026 e WebMCP: o teu site preparado para agentes IA.