MCP vs A2A: Guía completa de protocolos para agentes de IA en 2026

Si estás construyendo algo con agentes de IA en 2026, seguro escuchaste dos siglas constantemente: MCP y A2A. Y probablemente también escuchaste opiniones completamente opuestas. "MCP es el USB-C de la IA." "A2A reemplaza a MCP." "Necesitás los dos." "Ninguno está listo para producción."

La realidad: resuelven problemas completamente diferentes, y confundirlos es uno de los errores más comunes en la ingeniería de IA hoy. MCP se encarga de cómo un agente habla con herramientas. A2A se encarga de cómo los agentes hablan entre sí. Si confundís eso, tu arquitectura te va a pelear en cada esquina.

Este artículo desarma los dos protocolos desde cero — arquitectura, flujos de mensajes, código real y patrones prácticos de implementación. Al final vas a saber exactamente cómo encajan juntos y cuándo usar cuál.

Los dos problemas que nadie pensó

Antes de MCP y A2A, cada integración de herramientas con IA era artesanal. ¿Conectar Claude a una base de datos? Código custom. ¿Conectar GPT a Slack? Otro código custom. ¿Coordinar dos agentes de IA? Buena suerte — había que construir todo desde cero cada vez.

Esto creó dos pesadillas de integración distintas:

Problema 1: Integración de herramientas (resuelto por MCP)
Cada proveedor tenía su forma de conectar herramientas externas. OpenAI tenía function calling, Anthropic tenía tool use, Google tenía function declarations. Esquemas JSON diferentes, formatos de respuesta diferentes, manejo de errores diferente. Si armabas un conector Postgres para Claude, no podías reutilizarlo para GPT sin reescribir porciones significativas.

Problema 2: Coordinación de agentes (resuelto por A2A)
Cuando los equipos empezaron a armar sistemas multi-agente, no había forma estándar de que los agentes se descubrieran, negociaran capacidades o delegaran tareas. Si tenías un "agente de investigación" y un "agente de redacción", coordinarlos era puro código de orquestación manual. ¿Cambiar un agente por otro? Reescribir toda la capa de orquestación.

MCP y A2A son respuestas específicas a estos dos problemas distintos. Entender esta separación es la clave de todo.

MCP: Model Context Protocol — A fondo

Qué es MCP exactamente

MCP (Model Context Protocol), creado por Anthropic y donado a la AAIF (Agentic AI Foundation) de la Linux Foundation en diciembre 2025, estandariza cómo un agente de IA se conecta a herramientas externas, fuentes de datos y servicios. Pensalo como la interfaz estándar entre el cerebro de la IA y sus manos.

A febrero de 2026, las descargas de los SDKs de MCP superan los 97 millones mensuales (Python + TypeScript combinados) y fue adoptado por todos los grandes: Anthropic, OpenAI, Google, Microsoft, Amazon.

Arquitectura

MCP usa una arquitectura cliente-servidor con JSON-RPC 2.0:

┌─────────────────────┐     JSON-RPC 2.0      ┌──────────────────┐
│                     │ ◄──────────────────►   │                  │
│   MCP Client        │     (stdio, SSE,       │   MCP Server     │
│   (Agente IA/Host)  │      HTTP Streaming)   │   (Proveedor)    │
│                     │                        │                  │
│  ┌───────────────┐  │                        │  ┌────────────┐  │
│  │ Claude/GPT/   │  │   Request:             │  │ Resources  │  │
│  │ Gemini/Local  │──┼──► tools/call ────────►│  │ (datos)    │  │
│  │               │  │                        │  ├────────────┤  │
│  │               │◄─┼── Resultado/Error ◄───│  │ Tools      │  │
│  └───────────────┘  │                        │  │ (acciones) │  │
│                     │                        │  ├────────────┤  │
│                     │                        │  │ Prompts    │  │
│                     │                        │  │ (templates)│  │
│                     │                        │  ├────────────┤  │
│                     │                        │  │ Sampling   │  │
│                     │                        │  │ (LLM calls)│  │
│                     │                        │  └────────────┘  │
└─────────────────────┘                        └──────────────────┘

Un servidor MCP expone cuatro tipos de capacidades:

1. Resources — Fuentes de datos de solo lectura (archivos, registros de BD, respuestas de API)
2. Tools — Acciones ejecutables (correr una query, enviar un email, crear un archivo)
3. Prompts — Templates de prompts reutilizables con argumentos estructurados
4. Sampling — Capacidad de solicitar completions LLM al cliente (dirección inversa)

Construyendo un servidor MCP

Un servidor MCP práctico en TypeScript que provee capacidades de consulta a base de datos:

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 tablas disponibles
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: Ejecutar query de solo lectura
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 }) => {
    // Seguridad: solo permitir 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: Obtener schema de una tabla
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: Generar un prompt de análisis
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 el servidor
const transport = new StdioServerTransport();
await server.connect(transport);

Este servidor funciona con Claude Desktop, VS Code Copilot, Cursor o cualquier cliente compatible con MCP. Sin modificaciones.

Mecanismos de transporte

MCP soporta tres mecanismos de transporte, cada uno para escenarios distintos:

El transporte stdio es el más común para desarrollo local — herramientas como Claude Desktop lanzan servidores MCP como procesos hijos. Para producción, Streamable HTTP se está convirtiendo en el estándar.

Ecosistema MCP en 2026

El ecosistema explotó. A marzo de 2026:

• 5,800+ servidores MCP en registros públicos
• Servidores oficiales para: GitHub, Slack, PostgreSQL, Google Drive, Stripe, AWS, Jira, Linear, Notion
• Soporte MCP nativo en: Claude Desktop, VS Code, Cursor, Windsurf, Zed, JetBrains IDEs
• Ejecución de código: Los servidores MCP pueden ejecutar código para filtrar y transformar datos antes de enviarlos al LLM, reduciendo consumo de tokens dramáticamente

La promesa de "escribilo una vez, usalo en todos lados" está funcionando de verdad. Un servidor MCP de Postgres que armás hoy funciona en todos los clientes IA principales.

A2A: Agent-to-Agent Protocol — A fondo

Qué es A2A exactamente

A2A (Agent-to-Agent), creado por Google en abril 2025 y donado a la Linux Foundation en junio 2025, estandariza cómo los agentes de IA se descubren, comunican y colaboran entre sí — sin importar su framework subyacente. Pensalo como HTTP para agentes de IA.

El protocolo ganó tracción rápido: el Agent Communication Protocol (ACP) de IBM se fusionó con A2A en agosto 2025, y en diciembre 2025 la Linux Foundation lanzó la AAIF (Agentic AI Foundation) — co-fundada por OpenAI, Anthropic, Google, Microsoft, AWS y Block — como hogar permanente tanto para A2A como para MCP. A febrero 2026, más de 100 empresas se sumaron como apoyo, y el stack de tres capas (MCP para herramientas, A2A para agentes, WebMCP para web) se está consolidando.

Arquitectura

A2A usa una arquitectura cliente-remoto con JSON-over-HTTP:

┌─────────────────────┐       HTTP/JSON         ┌──────────────────┐
│                     │ ◄────────────────────►   │                  │
│   Cliente Agent     │                          │   Agente Remoto  │
│   (Orquestador)     │                          │   (Especialista) │
│                     │    1. Descubrimiento      │                  │
│  "Necesito esto"    │ ──► GET /agent.json ────►│  Agent Card      │
│                     │ ◄── capacidades ◄───────│  (manifiesto JSON)│
│                     │                          │                  │
│                     │    2. Ciclo de Tarea      │                  │
│                     │ ──► tasks/send ──────────►│  Procesar tarea  │
│                     │ ◄── updates de estado ◄──│  (puede ser async)│
│                     │                          │                  │
│                     │    3. Streaming           │                  │
│                     │ ──► tasks/sendSubscribe ─►│  Tiempo real     │
│                     │ ◄── SSE events ◄────────│  progreso         │
│                     │                          │                  │
│                     │    4. Artefactos          │                  │
│                     │ ◄── resultados ◄────────│  Entregables      │
└─────────────────────┘                          └──────────────────┘

Los conceptos core:

1. Agent Card — Manifiesto JSON (servido en /.well-known/agent.json) que describe lo que un agente puede hacer, sus requisitos de autenticación y capacidades soportadas
2. Tasks — La unidad de trabajo entre agentes. Las tareas tienen estados: submitted, working, input-required, completed, failed, canceled
3. Messages — Comunicación dentro de una tarea, cada uno con uno o más Parts (texto, archivo, datos)
4. Artifacts — Los outputs/entregables producidos por una tarea completada
5. Streaming — Updates en tiempo real vía Server-Sent Events para tareas de larga duración

Agent Cards: El mecanismo de descubrimiento

Un Agent Card es cómo los agentes publican lo que pueden hacer. Vive en una URL conocida:

{
  "name": "Code Review Agent",
  "description": "Review automático con análisis de seguridad, profiling de performance y chequeo 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": "Escaneo de Vulnerabilidades",
      "description": "Escanea código para vulnerabilidades OWASP Top 10, riesgos de dependencias y exposición de secretos",
      "tags": ["security", "OWASP", "vulnerability"],
      "examples": [
        "Revisá este PR por vulnerabilidades de seguridad",
        "Escaneá el módulo de auth por riesgos de inyección"
      ]
    },
    {
      "id": "performance-review",
      "name": "Análisis de Performance",
      "description": "Analiza N+1 queries, memory leaks, re-renders innecesarios e impacto en bundle size",
      "tags": ["performance", "optimization", "memory"],
      "examples": [
        "Chequeá este componente por problemas de performance",
        "Analizá los patrones de queries de este servicio"
      ]
    }
  ]
}

Lo potente: un agente cliente puede descubrir programáticamente las capacidades de un agente remoto, evaluar si es el correcto para el trabajo y engancharlo — todo sin configuración previa.

Ciclo de vida de tareas

Así funciona una interacción A2A completa en código:

// Agente cliente: Enviar tarea al 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: "Revisá el PR #42 por vulnerabilidades de seguridad. El PR modifica el flujo de autenticación y agrega un nuevo proveedor 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 contiene los hallazgos del review

Para tareas de larga duración, se usa streaming:

// Streamear progreso de tarea 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 del codebase completo" }],
        },
      },
    }),
  }
);

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

  switch (update.result.status.state) {
    case "working":
      console.log("Agente trabajando:", update.result.status.message);
      break;
    case "input-required":
      // El agente remoto necesita más información
      console.log("Agente necesita input:", update.result.status.message);
      break;
    case "completed":
      console.log("Review completo:", update.result.artifacts);
      eventSource.close();
      break;
  }
});

A2A vs llamadas API directas

Podrías preguntarte: "¿Por qué no llamar directamente a la API de otro agente?" La respuesta: estandarización y composabilidad.

El stack de tres capas

Acá es donde todo encaja. La arquitectura de consenso para sistemas de IA en 2026 es un stack de tres capas:

┌──────────────────────────────────────────────────────────┐
│                    Tu Aplicación                          │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  Layer 3: A2A (agente ↔ agente)                          │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐           │
│  │ Research │◄──►│ Planning │◄──►│ Execute  │           │
│  │ Agent    │    │ Agent    │    │ Agent    │           │
│  └─────┬────┘    └─────┬────┘    └─────┬────┘           │
│        │               │               │                 │
│  Layer 2: MCP (agente ↔ herramienta)                     │
│  ┌─────┴────┐    ┌─────┴────┐    ┌─────┴────┐           │
│  │ Bing     │    │ Calendar │    │ GitHub   │           │
│  │ Search   │    │ API      │    │ Actions  │           │
│  │ Server   │    │ Server   │    │ Server   │           │
│  └──────────┘    └──────────┘    └──────────┘           │
│                                                          │
│  Layer 1: WebMCP (agente ↔ web)                          │
│  ┌──────────────────────────────────────────┐            │
│  │ Acceso web estructurado para agentes      │            │
│  │ (llms.txt, sitemaps para agentes)         │            │
│  └──────────────────────────────────────────┘            │
│                                                          │
└──────────────────────────────────────────────────────────┘

Layer 1 — WebMCP: Acceso web estructurado. Los sitios publican llms.txt y contenido machine-readable. Todavía temprano pero creciendo.

Layer 2 — MCP: Agente-herramienta. Cada agente usa MCP para acceder a las herramientas y datos que necesita. El explorer de Postgres, la integración con GitHub, el conector de Slack — son todos servidores MCP.

Layer 3 — A2A: Agente-agente. Cuando el agente de research necesita al agente de planning, A2A coordina. Cada agente mantiene sus propias conexiones MCP pero se comunica con pares vía A2A.

Ejemplo real: Pipeline de PR automatizado

Pongamos todo junto con un escenario realista — un pipeline de review automatizado:

// Orquestador: Coordina el 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> {
    // Paso 1: Descubrir capacidades de los agentes
    const [secCard, perfCard, styleCard] = await Promise.all([
      this.securityAgent.getAgentCard(),
      this.perfAgent.getAgentCard(),
      this.styleAgent.getAgentCard(),
    ]);

    // Paso 2: Enviar tareas a todos los agentes en paralelo vía A2A
    const [secResult, perfResult, styleResult] = await Promise.all([
      this.securityAgent.sendTask({
        id: `sec-${Date.now()}`,
        message: {
          role: "user",
          parts: [
            { type: "text", text: `Review de seguridad para: ${prUrl}` },
            { type: "data", data: { diff } },
          ],
        },
      }),
      this.perfAgent.sendTask({
        id: `perf-${Date.now()}`,
        message: {
          role: "user",
          parts: [
            { type: "text", text: `Análisis de performance para: ${prUrl}` },
            { type: "data", data: { diff } },
          ],
        },
      }),
      this.styleAgent.sendTask({
        id: `style-${Date.now()}`,
        message: {
          role: "user",
          parts: [
            { type: "text", text: `Chequeo de estilo para: ${prUrl}` },
            { type: "data", data: { diff } },
          ],
        },
      }),
    ]);

    // Cada agente internamente usa MCP para acceder a:
    // - GitHub MCP server (contexto completo de archivos)
    // - SonarQube MCP server (agente de seguridad)
    // - Lighthouse MCP server (agente de performance)
    // - ESLint MCP server (agente de estilo)

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

En este setup:

• A2A maneja la comunicación orquestador ↔ agentes especialistas
• MCP maneja el acceso de cada agente a sus herramientas (GitHub, SonarQube, etc.)
• El orquestador no necesita saber nada de las herramientas — solo delega vía A2A

Comparación directa

Cuándo se superponen — y cuándo no

Hay una zona gris donde podrías preguntarte "¿esto debería ser MCP o A2A?" Acá el framework de decisión:

Usá MCP cuando:

• Exponés una herramienta determinística (BD, API, file system)
• La interacción es request-response (llamar una función, recibir un resultado)
• El "servidor" no tiene inteligencia propia ni toma decisiones
• Querés compatibilidad amplia con clientes IA

Usá A2A cuando:

• El sistema remoto tiene capacidad de razonamiento IA propio
• Las tareas son de larga duración o requieren negociación ida y vuelta
• Necesitás que el sistema remoto tome decisiones autónomas
• Querés descubrimiento de agentes y matching de capacidades

La zona de superposición:
Imaginá un servicio que resume documentos. ¿Es un tool MCP o un agente A2A?

• Si es una función fija (input: documento → output: resumen), hacelo servidor MCP
• Si decide cómo resumir según el contexto, puede hacer preguntas clarificadoras o coordinar con otros servicios, hacelo agente A2A

Regla sencilla: MCP para herramientas, A2A para pares.

Consideraciones de seguridad

Ambos protocolos tienen superficies de seguridad distintas:

Seguridad MCP

MCP es deliberadamente auth-agnostic — el protocolo no prescribe cómo autenticar:

// La responsabilidad cae en el implementador del servidor MCP
const server = new McpServer({
  name: "enterprise-db",
  version: "1.0.0",
});

// Tenés que implementar tu propio control de acceso
server.tool("query", "Run a database query", { sql: z.string() },
  async ({ sql }, { authContext }) => {
    // Validar permisos del usuario
    if (!authContext?.permissions?.includes("db:read")) {
      return { content: [{ type: "text", text: "Unauthorized" }], isError: true };
    }

    // Validar la query misma
    const sanitized = await validateAndSanitize(sql);
    // ...
  }
);

Preocupaciones clave de seguridad MCP:

• Tool poisoning: Un servidor MCP malicioso puede retornar datos que manipulan el comportamiento del LLM
• Over-permissioning: Los servidores MCP suelen tener acceso amplio (base de datos completa, file system entero)
• Riesgo de supply chain: Instalar un servidor MCP de un registro público es como instalar un paquete npm — verificá qué hace
• Prompt injection vía herramientas: Los datos retornados por herramientas MCP pueden contener instrucciones inyectadas

Seguridad A2A

A2A tiene más primitivas de seguridad built-in porque está diseñado para comunicación cross-boundary:

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

Preocupaciones clave A2A:

• Impersonación de agentes: Un agente que dice tener capacidades que no tiene
• Fuga de datos de tareas: Datos sensibles pasados entre agentes cruzando límites de confianza
• Ataques en cascada: Un agente comprometido usando A2A para atacar otros agentes de la red
• Audit trail: Asegurar que todas las acciones agente-agente sean rastreables y logeadas

Mejores prácticas combinadas

Para sistemas de producción usando ambos protocolos:

1. Mínimo privilegio: Cada servidor MCP debería exponer solo las herramientas mínimas necesarias
2. mTLS para A2A: Cuando los agentes se comunican entre redes, usá mTLS
3. Validación de input en todo: No confíes en datos de herramientas MCP ni de agentes A2A sin validar
4. Logging de auditoría: Logear cada tool call MCP y cada task A2A para trazabilidad
5. Rate limiting: Ambos protocolos necesitan rate limiting para prevenir abuso
6. Sandboxing: Correr servidores MCP en ambientes aislados (containers, VMs)

Patrones de implementación para producción

Patrón 1: Agente Gateway

El patrón más común. Un agente gateway maneja las interacciones del usuario y delega a agentes especializados vía A2A:

Usuario ──► Agente Gateway ──A2A──► Agente Especialista A
                             ──A2A──► Agente Especialista B
                             ──A2A──► Agente Especialista C
                         
Cada especialista usa MCP para acceder a sus herramientas

Cuándo usarlo: Aplicaciones customer-facing, chatbots, herramientas internas de productividad.

Patrón 2: Pipeline

Agentes encadenados en secuencia, cada uno procesando y pasando resultados:

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

Cuándo usarlo: Pipelines de procesamiento de datos, workflows documentales, chequeos de compliance.

Patrón 3: Mesh

Agentes comunicándose peer-to-peer según necesidades dinámicas:

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

Cuándo usarlo: Tareas de investigación complejas, sistemas autónomos, cuando la distribución de trabajo es impredecible.

Patrón 4: Solo MCP (sin A2A)

No sobreingeniés. Si tenés un agente que necesita herramientas, MCP solo alcanza:

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

Cuándo usarlo: La mayoría de las aplicaciones single-agent. Cursor + servidores MCP, Claude Desktop + herramientas, VS Code + Copilot.

Errores comunes

Error 1: Usar A2A cuando MCP alcanza

Si tus "agentes" son en realidad funciones determinísticas envueltas en llamadas LLM, no necesitás A2A. Un servidor MCP delgado es más simple, más rápido y más portable.

Red flag: Tu "agente" siempre produce el mismo output para el mismo input. Eso es una herramienta, no un agente. Usá MCP.

Error 2: Ignorar la seguridad del servidor MCP

Los servidores MCP corren con los permisos de tu aplicación. Un servidor de BD sin restricciones es un desastre esperando a pasar. Siempre limitá el scope y validá inputs.

Error 3: Construir tu propio protocolo

Si en 2026 estás escribiendo endpoints HTTP custom para comunicación de agentes, estás creando deuda técnica. Los dos tienen SDKs maduros, ecosistemas crecientes y adopción industrial. Usalos.

Error 4: Confundir los dos

"Armamos un servidor MCP que coordina múltiples agentes" — No. Si coordina agentes, querés A2A. Los servidores MCP exponen herramientas a agentes; no orquestan agentes.

Error 5: Arquitectura multi-agente prematura

No todo sistema necesita múltiples agentes. Empezá con un agente + herramientas MCP. Sumá A2A cuando tengas razones genuinas para autonomía y especialización de agentes. Los sistemas multi-agente son más difíciles de debuguear, más caros de correr y más lentos para responder.

El factor AAIF

Los dos protocolos están ahora bajo la AAIF (Agentic AI Foundation) de la Linux Foundation, lanzada en diciembre 2025 con seis co-fundadores: OpenAI, Anthropic, Google, Microsoft, AWS y Block. Esto es significativo porque:

1. Gobernanza neutral: Ni Anthropic ni Google controlan las specs solos
2. Presión de convergencia: Los dos protocolos van a evolucionar juntos. Esperá puntos de integración más estrechos
3. Confianza empresarial: La gobernanza por fundación hace que ambos protocolos sean seguros para adopción enterprise
4. Community-driven: Las propuestas de features pasan por procesos de RFC abiertos

La AAIF también supervisa WebMCP (la tercera capa). Mantené el ojo acá — el stack de tres capas se está solidificando rápido.

Qué viene después

Ambos protocolos están evolucionando rápido. Basado en propuestas en sus respectivos procesos de RFC:

Roadmap MCP:

• OAuth 2.1 built-in: Pasando de auth-agnostic a soporte OAuth de primera clase
• Tool chaining: Definir secuencias de tool calls como operaciones atómicas
• Modelo de seguridad mejorado: Sistemas de permisos estandarizados y guías de sandboxing
• Integración WebMCP: Conexión más profunda con contenido web

Roadmap A2A:

• Registros de agentes: Directorios centralizados para descubrir agentes entre organizaciones
• Negociación de contratos: Agentes acordando SLAs y restricciones de calidad antes de ejecutar tareas
• Tareas multi-party: Más de dos agentes participando en una sola tarea
• Hooks de compliance enterprise: Formatos de audit trail específicos para SOC2, GDPR y HIPAA

Conclusión

Dejá de pensar en MCP y A2A como competidores. Son capas del mismo stack:

MCP le da manos a tu agente. A2A le da colegas.

Si estás armando un agente que necesita acceso a herramientas, empezá con MCP. Es maduro, tiene soporte amplio y un ecosistema masivo de servidores pre-armados.

Si estás armando un sistema multi-agente donde agentes especializados necesitan descubrirse, delegar tareas y colaborar, sumá A2A encima.

Si estás armando un sistema enterprise, usá los dos — bajo el paraguas de gobernanza de la AAIF.

El peor error que podés cometer en 2026 es armar otra capa de integración custom. Los estándares están. Los SDKs son producción-ready. Los ecosistemas crecen exponencialmente.

Construí sobre el stack. Shipeá rápido. Pasá a los problemas que realmente importan.