MCP vs A2A: Guia completo dos protocolos de agentes de IA em 2026

Se você tá construindo qualquer coisa com agentes de IA em 2026, provavelmente já ouviu duas siglas o tempo todo: MCP e A2A. E deve ter ouvido opiniões completamente opostas sobre elas. "MCP é o USB-C da IA." "A2A substitui o MCP." "Você precisa dos dois." "Nenhum tá pronto pra produção."

A real: eles resolvem problemas completamente diferentes, e confundir os dois é um dos erros mais comuns na engenharia de IA hoje. MCP cuida de como um agente conversa com ferramentas. A2A cuida de como agentes conversam entre si. Erra isso e sua arquitetura vai brigar com você o tempo todo.

Este artigo desmonta os dois protocolos do zero — arquitetura, fluxos de mensagem, código de verdade e padrões práticos de implementação. No final você vai saber exatamente como eles se encaixam e quando usar qual.

Os dois problemas que ninguém pensou

Antes de MCP e A2A, toda integração de ferramenta com IA era artesanal. Conectar Claude num banco de dados? Código custom. Conectar GPT no Slack? Outro código custom. Coordenar dois agentes? Boa sorte — era tudo do zero toda vez.

Isso criou dois pesadelos de integração distintos:

Problema 1: Integração de ferramentas (resolvido pelo MCP)
Cada provedor de IA tinha seu jeito de conectar ferramentas externas. OpenAI com function calling, Anthropic com tool use, Google com function declarations. Schemas JSON diferentes, formatos de resposta diferentes, tratamento de erro diferente. Se você fazia um conector Postgres pro Claude, não dava pra reutilizar pro GPT sem reescrever pedaços enormes.

Problema 2: Coordenação de agentes (resolvido pelo A2A)
Quando times começaram a montar sistemas multi-agente, não tinha jeito padrão dos agentes se descobrirem, negociarem capacidades ou delegarem tarefas. Se você tinha um "agente de pesquisa" e um "agente de escrita", coordenar os dois era código de orquestração manual. Trocar um agente por outro? Reescrever toda a camada de orquestação.

MCP e A2A são respostas específicas pra esses dois problemas distintos. Entender essa separação é a chave de tudo.

MCP: Model Context Protocol — A fundo

O que é MCP na prática

MCP (Model Context Protocol), criado pela Anthropic e doado pra AAIF (Agentic AI Foundation) da Linux Foundation em dezembro de 2025, padroniza como um agente de IA se conecta a ferramentas externas, fontes de dados e serviços. Pensa nele como a interface padrão entre o cérebro da IA e suas mãos.

Em fevereiro de 2026, os downloads dos SDKs do MCP passaram 97 milhões/mês (Python + TypeScript somados) e foi adotado por todos os grandes: Anthropic, OpenAI, Google, Microsoft, Amazon.

Arquitetura

MCP usa arquitetura cliente-servidor com JSON-RPC 2.0:

┌─────────────────────┐     JSON-RPC 2.0      ┌──────────────────┐
│                     │ ◄──────────────────►   │                  │
│   MCP Client        │     (stdio, SSE,       │   MCP Server     │
│   (Agente IA/Host)  │      HTTP Streaming)   │   (Provedor)     │
│                     │                        │                  │
│  ┌───────────────┐  │                        │  ┌────────────┐  │
│  │ Claude/GPT/   │  │   Requisição:          │  │ Resources  │  │
│  │ Gemini/Local  │──┼──► tools/call ────────►│  │ (dados)    │  │
│  │               │  │                        │  ├────────────┤  │
│  │               │◄─┼── Resultado/Erro ◄────│  │ Tools      │  │
│  └───────────────┘  │                        │  │ (ações)    │  │
│                     │                        │  ├────────────┤  │
│                     │                        │  │ Prompts    │  │
│                     │                        │  │ (templates)│  │
│                     │                        │  ├────────────┤  │
│                     │                        │  │ Sampling   │  │
│                     │                        │  │ (LLM calls)│  │
│                     │                        │  └────────────┘  │
└─────────────────────┘                        └──────────────────┘

Um servidor MCP expõe quatro tipos de capacidade:

1. Resources — Fontes de dados somente leitura (arquivos, registros de BD, respostas de API)
2. Tools — Ações executáveis (rodar query, mandar email, criar arquivo)
3. Prompts — Templates de prompt reutilizáveis com argumentos estruturados
4. Sampling — Capacidade de pedir completions LLM ao cliente (direção reversa)

Construindo um servidor MCP

Um servidor MCP prático em TypeScript com capacidades de consulta a banco:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import postgres from "postgres";

const sql = postgres(process.env.DATABASE_URL!);

const server = new McpServer({
  name: "postgres-explorer",
  version: "1.0.0",
});

// Resource: Listar tabelas disponíveis
server.resource(
  "tables",
  "postgres://tables",
  async (uri) => {
    const tables = await sql`
      SELECT table_name FROM information_schema.tables
      WHERE table_schema = 'public'
    `;
    return {
      contents: [{
        uri: uri.href,
        mimeType: "application/json",
        text: JSON.stringify(tables, null, 2),
      }],
    };
  }
);

// Tool: Executar query somente leitura
server.tool(
  "query",
  "Execute a read-only SQL query against the database",
  {
    sql: z.string().describe("The SQL query to execute (SELECT only)"),
  },
  async ({ sql: query }) => {
    // Segurança: permitir apenas SELECT
    if (!query.trim().toUpperCase().startsWith("SELECT")) {
      return {
        content: [{ type: "text", text: "Error: Only SELECT queries allowed" }],
        isError: true,
      };
    }

    const result = await sql.unsafe(query);
    return {
      content: [{
        type: "text",
        text: JSON.stringify(result, null, 2),
      }],
    };
  }
);

// Tool: Pegar schema de uma tabela
server.tool(
  "describe-table",
  "Get the schema of a specific table",
  {
    tableName: z.string().describe("Name of the table to describe"),
  },
  async ({ tableName }) => {
    const columns = await sql`
      SELECT column_name, data_type, is_nullable, column_default
      FROM information_schema.columns
      WHERE table_name = ${tableName} AND table_schema = 'public'
      ORDER BY ordinal_position
    `;
    return {
      content: [{
        type: "text",
        text: JSON.stringify(columns, null, 2),
      }],
    };
  }
);

// Prompt: Gerar um prompt de análise
server.prompt(
  "analyze-table",
  "Generate a prompt to analyze data in a specific table",
  {
    tableName: z.string().describe("Table to analyze"),
    focus: z.string().optional().describe("Specific aspect to focus on"),
  },
  async ({ tableName, focus }) => ({
    messages: [{
      role: "user",
      content: {
        type: "text",
        text: `Analyze the "${tableName}" table in our PostgreSQL database.${
          focus ? ` Focus specifically on: ${focus}.` : ""
        } Start by examining the schema, then run queries to understand the data distribution, identify patterns, and surface any anomalies.`,
      },
    }],
  })
);

// Iniciar o servidor
const transport = new StdioServerTransport();
await server.connect(transport);

Esse servidor funciona no Claude Desktop, VS Code Copilot, Cursor ou qualquer cliente compatível com MCP. Sem modificação nenhuma.

Mecanismos de transporte

MCP suporta três mecanismos de transporte, cada um pra um cenário diferente:

O transporte stdio é o mais comum pro desenvolvimento local — ferramentas como Claude Desktop criam servidores MCP como processos filhos. Pra produção, Streamable HTTP tá se tornando o padrão.

Ecossistema MCP em 2026

O ecossistema explodiu. Em março de 2026:

• 5.800+ servidores MCP em registros públicos
• Servidores oficiais pra: GitHub, Slack, PostgreSQL, Google Drive, Stripe, AWS, Jira, Linear, Notion
• Suporte MCP nativo em: Claude Desktop, VS Code, Cursor, Windsurf, Zed, JetBrains IDEs
• Execução de código: Servidores MCP podem executar código pra filtrar e transformar dados antes de mandar pro LLM, reduzindo consumo de tokens drasticamente

A promessa do "escreve uma vez, usa em todo lugar" tá realmente funcionando. Um servidor MCP de Postgres que você constrói hoje funciona em todo cliente IA principal.

A2A: Agent-to-Agent Protocol — A fundo

O que é A2A na prática

A2A (Agent-to-Agent), criado pelo Google em abril de 2025 e doado pra Linux Foundation em junho de 2025, padroniza como agentes de IA se descobrem, se comunicam e colaboram — independente do framework. Pensa nele como HTTP pra agentes de IA.

O protocolo ganhou tração rápido: o Agent Communication Protocol (ACP) da IBM foi incorporado ao A2A em agosto de 2025, e em dezembro de 2025 a Linux Foundation lançou a AAIF (Agentic AI Foundation) — co-fundada por OpenAI, Anthropic, Google, Microsoft, AWS e Block — como casa permanente tanto pro A2A quanto pro MCP. Até fevereiro de 2026, mais de 100 empresas entraram como apoiadoras, e o stack de três camadas (MCP pra ferramentas, A2A pra agentes, WebMCP pra web) tá virando a arquitetura de consenso.

Arquitetura

A2A usa arquitetura cliente-remoto com JSON-over-HTTP:

┌─────────────────────┐       HTTP/JSON         ┌──────────────────┐
│                     │ ◄────────────────────►   │                  │
│   Agente Cliente    │                          │   Agente Remoto  │
│   (Orquestrador)    │                          │   (Especialista) │
│                     │    1. Descoberta          │                  │
│  "Preciso disso"    │ ──► GET /agent.json ────►│  Agent Card      │
│                     │ ◄── capacidades ◄───────│  (manifesto JSON)│
│                     │                          │                  │
│                     │    2. Ciclo de Tarefa     │                  │
│                     │ ──► tasks/send ──────────►│  Processar tarefa│
│                     │ ◄── updates de status ◄──│  (pode ser async)│
│                     │                          │                  │
│                     │    3. Streaming           │                  │
│                     │ ──► tasks/sendSubscribe ─►│  Tempo real      │
│                     │ ◄── SSE events ◄────────│  progresso        │
│                     │                          │                  │
│                     │    4. Artefatos           │                  │
│                     │ ◄── resultados ◄────────│  Entregáveis      │
└─────────────────────┘                          └──────────────────┘

Conceitos centrais:

1. Agent Card — Manifesto JSON (servido em /.well-known/agent.json) que descreve o que o agente sabe fazer, requisitos de autenticação e capacidades suportadas
2. Tasks — Unidade de trabalho entre agentes. Estados: submitted, working, input-required, completed, failed, canceled
3. Messages — Comunicação dentro de uma tarefa, cada uma com um ou mais Parts (texto, arquivo, dados)
4. Artifacts — Outputs/entregáveis produzidos por uma tarefa completada
5. Streaming — Updates em tempo real via Server-Sent Events pra tarefas longas

Agent Cards: O mecanismo de descoberta

Um Agent Card é como os agentes publicam o que sabem fazer. Vive numa URL conhecida:

{
  "name": "Code Review Agent",
  "description": "Review automatizado com análise de segurança, profiling de performance e checagem de estilo",
  "url": "https://code-review.example.com",
  "version": "2.1.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": true
  },
  "authentication": {
    "schemes": ["Bearer"],
    "credentials": "OAuth 2.0 token required"
  },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "security-review",
      "name": "Scan de Vulnerabilidades",
      "description": "Escaneia código pra vulnerabilidades OWASP Top 10, riscos de dependência e exposição de secrets",
      "tags": ["security", "OWASP", "vulnerability"],
      "examples": [
        "Revisa esse PR por vulnerabilidades de segurança",
        "Escaneia o módulo de auth por riscos de injeção"
      ]
    },
    {
      "id": "performance-review",
      "name": "Análise de Performance",
      "description": "Analisa N+1 queries, memory leaks, re-renders desnecessários e impacto no bundle size",
      "tags": ["performance", "optimization", "memory"],
      "examples": [
        "Checa esse componente por problemas de performance",
        "Analisa os padrões de query desse serviço"
      ]
    }
  ]
}

O poder disso: um agente cliente consegue descobrir as capacidades de um agente remoto programaticamente, avaliar se é o certo pro trabalho e engajá-lo — tudo sem configuração prévia.

Ciclo de vida de tarefas

Assim funciona uma interação A2A completa em código:

// Agente cliente: Mandar tarefa pro Code Review Agent
const response = await fetch("https://code-review.example.com/tasks/send", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Authorization": "Bearer <token>",
  },
  body: JSON.stringify({
    jsonrpc: "2.0",
    method: "tasks/send",
    id: "task-001",
    params: {
      id: "review-pr-42",
      message: {
        role: "user",
        parts: [
          {
            type: "text",
            text: "Revisa o PR #42 por vulnerabilidades de segurança. O PR modifica o fluxo de autenticação e adiciona um novo provider OAuth.",
          },
          {
            type: "data",
            data: {
              repository: "acme/backend",
              prNumber: 42,
              diffUrl: "https://github.com/acme/backend/pull/42.diff",
            },
          },
        ],
      },
    },
  }),
});

const result = await response.json();
// result.result.status.state === "completed"
// result.result.artifacts contém os achados do review

Pra tarefas de longa duração, usa streaming:

// Streamar progresso via SSE
const eventSource = new EventSource(
  "https://code-review.example.com/tasks/sendSubscribe",
  {
    method: "POST",
    body: JSON.stringify({
      jsonrpc: "2.0",
      method: "tasks/sendSubscribe",
      params: {
        id: "review-pr-42",
        message: {
          role: "user",
          parts: [{ type: "text", text: "Review profundo do codebase completo" }],
        },
      },
    }),
  }
);

eventSource.addEventListener("message", (event) => {
  const update = JSON.parse(event.data);

  switch (update.result.status.state) {
    case "working":
      console.log("Agente trabalhando:", update.result.status.message);
      break;
    case "input-required":
      // O agente remoto precisa de mais informação
      console.log("Agente precisa de input:", update.result.status.message);
      break;
    case "completed":
      console.log("Review completo:", update.result.artifacts);
      eventSource.close();
      break;
  }
});

A2A vs chamadas API diretas

Você pode se perguntar: "Por que não chamar a API de outro agente direto?" A resposta: padronização e composabilidade.

O stack de três camadas

Aqui tudo se encaixa. A arquitetura de consenso pra sistemas de IA em 2026 é um stack de três camadas:

┌──────────────────────────────────────────────────────────┐
│                    Sua Aplicação                          │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  Layer 3: A2A (agente ↔ agente)                          │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐           │
│  │ Research │◄──►│ Planning │◄──►│ Execute  │           │
│  │ Agent    │    │ Agent    │    │ Agent    │           │
│  └─────┬────┘    └─────┬────┘    └─────┬────┘           │
│        │               │               │                 │
│  Layer 2: MCP (agente ↔ ferramenta)                      │
│  ┌─────┴────┐    ┌─────┴────┐    ┌─────┴────┐           │
│  │ Bing     │    │ Calendar │    │ GitHub   │           │
│  │ Search   │    │ API      │    │ Actions  │           │
│  │ Server   │    │ Server   │    │ Server   │           │
│  └──────────┘    └──────────┘    └──────────┘           │
│                                                          │
│  Layer 1: WebMCP (agente ↔ web)                          │
│  ┌──────────────────────────────────────────┐            │
│  │ Acesso web estruturado pra agentes        │            │
│  │ (llms.txt, sitemaps pra agentes)          │            │
│  └──────────────────────────────────────────┘            │
│                                                          │
└──────────────────────────────────────────────────────────┘

Layer 1 — WebMCP: Acesso web estruturado. Sites publicam llms.txt e conteúdo machine-readable pra consumo de agentes. Ainda no começo mas crescendo.

Layer 2 — MCP: Agente-ferramenta. Cada agente usa MCP pra acessar as ferramentas e dados que precisa. O explorer de Postgres, a integração com GitHub, o conector do Slack — são todos servidores MCP.

Layer 3 — A2A: Agente-agente. Quando o agente de pesquisa precisa de ajuda do agente de planejamento, A2A coordena. Cada agente mantém suas próprias conexões MCP mas se comunica com pares via A2A.

Exemplo real: Pipeline de PR automatizado

Juntando tudo num cenário realista — um pipeline de review automatizado:

// Orquestrador: Coordena o pipeline de review usando A2A

import { A2AClient } from "@a2a/client";

class PRReviewOrchestrator {
  private securityAgent = new A2AClient("https://security-agent.internal");
  private perfAgent = new A2AClient("https://perf-agent.internal");
  private styleAgent = new A2AClient("https://style-agent.internal");

  async reviewPR(prUrl: string, diff: string): Promise<ReviewResult> {
    // Passo 1: Descobrir capacidades dos agentes
    const [secCard, perfCard, styleCard] = await Promise.all([
      this.securityAgent.getAgentCard(),
      this.perfAgent.getAgentCard(),
      this.styleAgent.getAgentCard(),
    ]);

    // Passo 2: Mandar tarefas pra todos os agentes em paralelo via A2A
    const [secResult, perfResult, styleResult] = await Promise.all([
      this.securityAgent.sendTask({
        id: `sec-${Date.now()}`,
        message: {
          role: "user",
          parts: [
            { type: "text", text: `Review de segurança pra: ${prUrl}` },
            { type: "data", data: { diff } },
          ],
        },
      }),
      this.perfAgent.sendTask({
        id: `perf-${Date.now()}`,
        message: {
          role: "user",
          parts: [
            { type: "text", text: `Análise de performance pra: ${prUrl}` },
            { type: "data", data: { diff } },
          ],
        },
      }),
      this.styleAgent.sendTask({
        id: `style-${Date.now()}`,
        message: {
          role: "user",
          parts: [
            { type: "text", text: `Checagem de estilo pra: ${prUrl}` },
            { type: "data", data: { diff } },
          ],
        },
      }),
    ]);

    // Cada agente internamente usa MCP pra acessar:
    // - GitHub MCP server (contexto completo dos arquivos)
    // - SonarQube MCP server (agente de segurança)
    // - Lighthouse MCP server (agente de performance)
    // - ESLint MCP server (agente de estilo)

    return this.synthesizeResults(secResult, perfResult, styleResult);
  }
}

Nesse setup:

• A2A cuida da comunicação orquestrador ↔ agentes especialistas
• MCP cuida do acesso de cada agente às suas ferramentas (GitHub, SonarQube, etc.)
• O orquestrador não precisa saber nada das ferramentas — só delega via A2A

Comparação direta

Quando se sobrepõem — e quando não

Tem uma zona cinza onde você pode se perguntar "isso deveria ser MCP ou A2A?" Aqui o framework de decisão:

Use MCP quando:

• Tá expondo uma ferramenta determinística (BD, API, file system)
• A interação é request-response (chama uma função, recebe um resultado)
• O "servidor" não tem inteligência própria nem toma decisões
• Quer compatibilidade ampla com clientes IA

Use A2A quando:

• O sistema remoto tem capacidade de raciocínio IA própria
• Tarefas são de longa duração ou precisam de negociação ida e volta
• Precisa que o sistema remoto tome decisões autônomas
• Quer descoberta de agentes e matching de capacidades

A zona de sobreposição:
Imagina um serviço que resume documentos. É um tool MCP ou um agente A2A?

• Se é uma função fixa (input: documento → output: resumo), faz ele servidor MCP
• Se ele decide como resumir baseado no contexto, pode fazer perguntas de esclarecimento ou coordenar com outros serviços, faz ele agente A2A

Regra simples: MCP pra ferramentas, A2A pra pares.

Considerações de segurança

Ambos os protocolos têm superfícies de segurança distintas:

Segurança MCP

MCP é deliberadamente auth-agnostic — o protocolo não prescreve como autenticar:

// A responsabilidade tá no implementador do servidor MCP
const server = new McpServer({
  name: "enterprise-db",
  version: "1.0.0",
});

// Você TEM que implementar seu próprio controle de acesso
server.tool("query", "Run a database query", { sql: z.string() },
  async ({ sql }, { authContext }) => {
    // Validar permissões do usuário
    if (!authContext?.permissions?.includes("db:read")) {
      return { content: [{ type: "text", text: "Unauthorized" }], isError: true };
    }

    // Validar a própria query
    const sanitized = await validateAndSanitize(sql);
    // ...
  }
);

Preocupações chave de segurança MCP:

• Tool poisoning: Um servidor MCP malicioso pode retornar dados que manipulam o comportamento do LLM
• Permissões excessivas: Servidores MCP frequentemente ganham acesso amplo (banco completo, file system inteiro)
• Risco de supply chain: Instalar um servidor MCP de um registro público é como instalar um pacote npm — verifica o que ele faz
• Prompt injection via ferramentas: Dados retornados por ferramentas MCP podem conter instruções injetadas

Segurança A2A

A2A tem mais primitivas de segurança built-in porque foi projetado pra comunicação cross-boundary:

{
  "authentication": {
    "schemes": ["Bearer"],
    "credentials": "OAuth 2.0 via https://auth.example.com"
  }
}

Preocupações chave A2A:

• Impersonação de agentes: Um agente dizendo ter capacidades que não tem
• Vazamento de dados de tarefas: Dados sensíveis passados entre agentes cruzando limites de confiança
• Ataques em cascata: Um agente comprometido usando A2A pra atacar outros agentes da rede
• Audit trail: Garantir que todas as ações agente-agente sejam rastreáveis e logadas

Práticas combinadas de segurança

Pra sistemas de produção usando ambos:

1. Mínimo privilégio: Cada servidor MCP deve expor apenas as ferramentas mínimas necessárias
2. mTLS pra A2A: Quando agentes se comunicam entre redes, use mTLS
3. Validação de input em tudo: Não confie em dados de ferramentas MCP nem de agentes A2A sem validar
4. Log de auditoria: Logue cada tool call MCP e cada task A2A pra rastreabilidade
5. Rate limiting: Ambos os protocolos precisam de rate limiting pra prevenir abuso
6. Sandboxing: Rode servidores MCP em ambientes isolados (containers, VMs)

Padrões de implementação pra produção

Padrão 1: Agente Gateway

O padrão mais comum. Um agente gateway gerencia as interações do usuário e delega pra agentes especializados via A2A:

Usuário ──► Agente Gateway ──A2A──► Agente Especialista A
                             ──A2A──► Agente Especialista B
                             ──A2A──► Agente Especialista C
                         
Cada especialista usa MCP pra acessar suas ferramentas

Quando usar: Aplicações customer-facing, chatbots, ferramentas internas de produtividade.

Padrão 2: Pipeline

Agentes encadeados em sequência, cada um processando e passando resultados:

Input ──► Agente 1 ──A2A──► Agente 2 ──A2A──► Agente 3 ──► Output
              │                 │                │
            MCP              MCP              MCP
              │                 │                │
          Data Source      Transform Tool    Output Tool

Quando usar: Pipelines de processamento de dados, workflows documentais, checagens de compliance.

Padrão 3: Mesh

Agentes se comunicando peer-to-peer conforme necessidades dinâmicas:

Agente A ◄──A2A──► Agente B
   ▲                  ▲
   │                  │
  A2A               A2A
   │                  │
   ▼                  ▼
Agente C ◄──A2A──► Agente D

Quando usar: Tarefas de pesquisa complexas, sistemas autônomos, quando a distribuição de trabalho é imprevisível.

Padrão 4: Só MCP (sem A2A)

Não complique demais. Se tem um agente que precisa de ferramentas, MCP sozinho resolve:

Agente Único ──MCP──► Tool Server 1
              ──MCP──► Tool Server 2
              ──MCP──► Tool Server 3

Quando usar: A maioria das aplicações single-agent. Cursor + servidores MCP, Claude Desktop + ferramentas, VS Code + Copilot.

Erros comuns

Erro 1: Usar A2A quando MCP resolve

Se seus "agentes" são na real funções determinísticas envoltas em chamadas LLM, não precisa de A2A. Um servidor MCP fino é mais simples, mais rápido e mais portável.

Red flag: Seu "agente" sempre produz o mesmo output pro mesmo input. Isso é uma ferramenta, não um agente. Use MCP.

Erro 2: Ignorar segurança de servidores MCP

Servidores MCP rodam com as permissões da sua aplicação. Um servidor de BD sem restrição é desastre esperando acontecer. Sempre limite o scope e valide inputs.

Erro 3: Construir protocolo próprio

Se em 2026 você tá escrevendo endpoints HTTP custom pra comunicação de agentes, tá criando dívida técnica. Os dois têm SDKs maduros, ecossistemas crescentes e adoção industrial. Use eles.

Erro 4: Confundir os dois

"Montamos um servidor MCP que coordena múltiplos agentes" — Não. Se coordena agentes, quer A2A. Servidores MCP expõem ferramentas pra agentes; não orquestram agentes.

Erro 5: Arquitetura multi-agente prematura

Nem todo sistema precisa de múltiplos agentes. Começa com um agente + ferramentas MCP. Adiciona A2A quando tiver razões genuínas pra autonomia e especialização de agentes. Sistemas multi-agente são mais difíceis de debugar, mais caros de rodar e mais lentos de responder.

O fator AAIF

Os dois protocolos tão agora sob a AAIF (Agentic AI Foundation) da Linux Foundation, lançada em dezembro de 2025 com seis co-fundadores: OpenAI, Anthropic, Google, Microsoft, AWS e Block. Isso é significativo porque:

1. Governança neutra: Nem Anthropic nem Google controlam as specs sozinhos
2. Pressão de convergência: Os dois protocolos vão evoluir juntos. Espere pontos de integração mais estreitos
3. Confiança empresarial: Governança por fundação torna ambos os protocolos seguros pra adoção enterprise
4. Community-driven: Propostas de features passam por processos de RFC abertos

A AAIF também supervisiona o WebMCP (a terceira camada). Fique de olho — o stack de três camadas tá se solidificando rápido.

O que vem depois

Ambos os protocolos tão evoluindo rápido. Baseado em propostas nos respectivos processos de RFC:

Roadmap MCP:

• OAuth 2.1 built-in: Saindo de auth-agnostic pra suporte OAuth de primeira classe
• Tool chaining: Definir sequências de tool calls como operações atômicas
• Modelo de segurança aprimorado: Sistemas de permissão padronizados e guias de sandboxing
• Integração WebMCP: Conexão mais profunda com conteúdo web

Roadmap A2A:

• Registros de agentes: Diretórios centralizados pra descobrir agentes entre organizações
• Negociação de contratos: Agentes concordando em SLAs e restrições de qualidade antes de executar tarefas
• Tarefas multi-party: Mais de dois agentes participando de uma única tarefa
• Hooks de compliance enterprise: Formatos de audit trail específicos pra SOC2, GDPR e HIPAA

Conclusão

Para de pensar em MCP e A2A como concorrentes. São camadas do mesmo stack:

MCP dá mãos ao seu agente. A2A dá colegas.

Se tá construindo um agente que precisa de acesso a ferramentas, começa com MCP. É maduro, tem suporte amplo e um ecossistema massivo de servidores pré-construídos.

Se tá construindo um sistema multi-agente onde agentes especializados precisam se descobrir, delegar tarefas e colaborar, adiciona A2A por cima.

Se tá construindo um sistema enterprise, use os dois — sob o guarda-chuva de governança da AAIF.

O pior erro que dá pra cometer em 2026 é construir outra camada de integração custom. Os padrões existem. Os SDKs são production-ready. Os ecossistemas crescem exponencialmente.

Constrói sobre o stack. Shipa rápido. Parte pros problemas que realmente importam.