MCP vs A2A vs ANP: protocolos de agentes IA

¿Qué son los protocolos para agentes IA y por qué importan?

Los protocolos para agentes IA son estándares abiertos que definen cómo los agentes se conectan a herramientas, se comunican entre sí y descubren pares en la red. Sin ellos, cada integración es un wrapper de API a medida. Con ellos, puedes cambiar el modelo o la herramienta y todo sigue funcionando.

Tres protocolos importan para desarrolladores que construyen sistemas de agentes: MCP (Model Context Protocol), A2A (Agent-to-Agent Protocol) y ANP (Agent Network Protocol). No son competidores. Son capas en un stack.

MCP conecta agentes con herramientas y datos. A2A permite a los agentes delegar tareas a otros agentes. ANP gestiona el descubrimiento entre redes. Si alojas agentes en un VPS, saber dónde encaja cada protocolo te evita sobredimensionar configuraciones simples o quedarte corto con las complejas.

Este artículo es el modelo mental. Sin código. Solo el mapa que necesitas antes de empezar a construir.

¿Qué es MCP (Model Context Protocol)?

MCP es un estándar abierto, creado originalmente por Anthropic, que define cómo los agentes IA se conectan a herramientas y fuentes de datos externas. Los servidores MCP exponen capacidades a clientes MCP integrados en aplicaciones IA. Piensa en MCP como un puerto USB para IA: una interfaz única entre cualquier agente y cualquier herramienta. Anthropic donó MCP a la Agentic AI Foundation (AAIF) bajo la Linux Foundation en diciembre de 2025.

Antes de MCP, conectar un modelo IA a una base de datos significaba escribir una integración a medida. Conectarlo a una segunda base requería otra más. MCP reemplaza ese patrón con un protocolo universal. Construyes un servidor MCP para tu base de datos, y cualquier agente compatible con MCP puede usarlo.

¿Cómo funciona MCP?

MCP define tres roles:

Host: La aplicación IA (Claude Desktop, Cursor, tu aplicación personalizada). Gestiona uno o más clientes MCP.
Client: Un conector dentro del host que mantiene una conexión 1:1 con un servidor MCP.
Server: Un servicio ligero que expone herramientas, recursos y prompts a los clientes.

La comunicación usa JSON-RPC 2.0 sobre uno de dos tipos de transporte:

stdio: Entrada/salida estándar. Ideal para servidores locales en la misma máquina. El host lanza el servidor como proceso hijo.
Streamable HTTP: Transporte basado en HTTP que permite a los servidores MCP funcionar como servicios remotos. El cliente envía peticiones JSON-RPC por HTTP POST. El servidor puede hacer streaming de respuestas. Esto permite ejecutar servidores MCP en un VPS y conectarse a ellos remotamente.

El transporte SSE anterior (Server-Sent Events) sigue funcionando, pero está siendo sustituido por Streamable HTTP, que soporta operación sin estado y escalado horizontal sin sesiones persistentes.

Los servidores MCP exponen tres tipos de primitivas:

Primitiva	Función	Control
Tools	Funciones que el modelo IA puede invocar (consultar una base de datos, enviar un email, ejecutar un script)	Controlado por el modelo (el LLM decide cuándo invocar)
Resources	Datos que el agente puede leer (archivos, registros, respuestas de API)	Controlado por la aplicación (el host decide qué exponer)
Prompts	Plantillas de mensajes y flujos de trabajo	Controlado por el usuario (el usuario selecciona entre los prompts disponibles)

Las conexiones mantienen estado. Cliente y servidor negocian capacidades durante la inicialización y luego intercambian mensajes sobre una conexión persistente. Los servidores también pueden solicitar sampling (pedir al LLM que genere texto) y elicitation (pedir entrada al usuario), lo que habilita comportamiento agéntico recursivo.

¿Cómo está el ecosistema MCP en 2026?

MCP es el protocolo de integración por defecto para herramientas IA en 2026:

97M+ descargas mensuales del SDK en Python y TypeScript
10.000+ servidores MCP públicos en producción
Adoptado por todas las grandes plataformas IA: Claude, ChatGPT, Gemini, Copilot, Cursor, VS Code
Gobernado por la AAIF bajo la Linux Foundation, cofundada por Anthropic, OpenAI y Block
Versión actual de la especificación: 2025-11-25

La hoja de ruta de 2026 se centra en llevar Streamable HTTP a producción a escala: manejo de peticiones sin estado, escalado horizontal simplificado y un método estándar para que los registros descubran capacidades de servidores sin conectarse.

¿Qué es A2A (Agent-to-Agent Protocol)?

A2A (Agent-to-Agent Protocol) es un protocolo abierto creado originalmente por Google que estandariza cómo los agentes IA se comunican y colaboran. Un agente envía una tarea a otro usando JSON-RPC sobre HTTP. El agente receptor publica una Agent Card que describe sus capacidades, requisitos de autenticación y URL del endpoint. A2A gestiona el ciclo de vida de las tareas, el streaming de resultados y las notificaciones push para operaciones de larga duración.

MCP conecta un agente con herramientas. A2A conecta un agente con otros agentes. Los servidores MCP son transparentes: ves exactamente lo que hacen. Los agentes A2A son opacos. El agente que llama no sabe ni necesita saber qué modelo, framework o lógica ejecuta el agente remoto. Envía una tarea y recibe resultados.

¿Cómo funciona A2A?

A2A define tres actores:

User: El humano o servicio automatizado que solicita trabajo.
A2A Client: La aplicación que envía tareas en nombre del usuario.
A2A Server: Un agente remoto que expone un endpoint HTTP. Opera como caja negra.

Las Agent Cards son el mecanismo de descubrimiento. Cada servidor A2A publica un documento JSON (normalmente en /.well-known/agent-card.json) que describe:

Identidad del agente (nombre, descripción, proveedor)
URL del endpoint de servicio
Capacidades soportadas (streaming, notificaciones push)
Skills disponibles con descripciones
Requisitos de autenticación
Firma digital opcional para verificación

Una Task (tarea) es la unidad de trabajo. Cada tarea tiene un ID único y progresa a través de un ciclo de vida:

submitted → working → completed
                   → failed
                   → canceled
                   → rejected
           → input-required (multi-turno: el agente necesita más información del cliente)

Los mensajes contienen Parts: texto, referencias a archivos o datos JSON estructurados. Los resultados de las tareas se llaman Artifacts, que también contienen Parts. Un agente puede devolver un archivo de código, un resumen de texto y un informe JSON en una sola respuesta.

A2A soporta tres patrones de comunicación:

Request/Response: El cliente envía una tarea, consulta el estado con GetTask.
Streaming (SSE): Actualizaciones incrementales en tiempo real sobre conexiones HTTP persistentes. El cliente llama a SendStreamingMessage y recibe eventos mientras el agente trabaja.
Push Notifications (Webhooks): Para tareas de larga duración, el agente envía actualizaciones de estado por POST a una URL webhook registrada por el cliente.

Toda la comunicación usa JSON-RPC 2.0 sobre HTTPS. La versión 0.3 añadió soporte gRPC y Agent Cards firmadas. La versión actual es A2A v1.0.0.

¿Cómo se fusionaron A2A y ACP?

IBM lanzó el Agent Communication Protocol (ACP) en marzo de 2025 para alimentar su plataforma BeeAI. Google anunció A2A al mes siguiente. Ambos protocolos resolvían el mismo problema: la comunicación entre agentes.

En agosto de 2025, la Linux Foundation anunció que ACP se fusionaría con A2A. El equipo ACP de IBM, liderado por Kate Blair, se unió al Comité de Dirección Técnica de A2A junto a Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow y SAP. La plataforma BeeAI pasó de ACP a A2A, y el desarrollo específico de ACP cesó.

Si estabas evaluando ACP por separado, para. La respuesta es A2A.

¿Qué es ANP (Agent Network Protocol)?

ANP (Agent Network Protocol) es un protocolo peer-to-peer que permite a los agentes IA descubrirse y comunicarse entre sí a través de redes abiertas sin autoridad central. A diferencia del modelo cliente-servidor de MCP y la delegación de tareas cliente-servidor de A2A, ANP trata a cada agente como un par igual. Usa identificadores descentralizados W3C (DIDs) para identidad, JSON-LD para intercambio de datos e incluye una capa de meta-protocolo donde los agentes negocian cómo se comunicarán.

ANP aborda un problema diferente al de MCP y A2A. Esos protocolos asumen que sabes qué servidor o agente quieres contactar. ANP responde a la pregunta: ¿cómo encuentra un agente a otros agentes con los que nunca ha interactuado, más allá de fronteras organizacionales, sin un directorio central?

¿En qué se diferencia ANP de A2A?

ANP tiene una arquitectura de tres capas:

Capa 1: Identidad y comunicación cifrada. Cada agente recibe un identificador descentralizado W3C usando el método did:wba (Web-Based Agent). Cada DID se mapea a un documento DID alojado en HTTPS, así que la resolución de identidad usa infraestructura web existente. Dos agentes pueden verificar mutuamente su identidad y establecer canales cifrados sin autoridad central.

Capa 2: Meta-protocolo. Los agentes negocian protocolos de comunicación dinámicamente. En lugar de que ambos agentes deban soportar el mismo protocolo fijo, intercambian requisitos en forma estructurada, acuerdan un protocolo y luego se comunican usándolo. Esto hace que ANP sea adaptable a escenarios que el enfoque JSON-RPC fijo de A2A no puede cubrir.

Capa 3: Protocolo de aplicación. Las descripciones de agentes usan JSON-LD vinculado a ontologías de schema.org. El descubrimiento funciona de dos formas:

Descubrimiento activo: Consultar el endpoint /.well-known/agent-descriptions de un dominio.
Descubrimiento pasivo: Los agentes se registran en servicios de indexación que rastrean y catalogan descripciones.

Comparación arquitectónica entre ANP y A2A:

Aspecto	A2A	ANP
Topología	Cliente-servidor	Peer-to-peer
Identidad	Agent Cards (JSON auto-publicado)	W3C DIDs (descentralizados, verificables)
Descubrimiento	URL conocida (`/.well-known/agent-card.json`)	Indexación descentralizada + endpoints well-known
Flexibilidad de protocolo	Fijo (JSON-RPC 2.0)	Negociación por meta-protocolo
Formato de datos	JSON Parts (texto, archivos, datos estructurados)	JSON-LD con enlace semántico

Estado actual: ANP está todavía en fase de propuesta y desarrollo temprano. Tiene un repositorio en GitHub y un libro blanco del W3C Community Group, pero no hay SDKs de producción ni adopción amplia. La especificación no está gobernada por la AAIF.

¿Cómo se comparan MCP, A2A y ANP?

Los tres protocolos comparados en las dimensiones que importan al diseñar un sistema de agentes:

	MCP	A2A	ANP
Problema resuelto	Conexión agente-herramienta	Delegación de tareas agente-agente	Descubrimiento y comunicación entre agentes en red abierta
Arquitectura	Cliente-servidor (host → client → server)	Cliente-servidor (client → agente remoto)	Peer-to-peer (agente ↔ agente)
Transporte	stdio, Streamable HTTP	HTTPS (JSON-RPC 2.0), SSE, gRPC	HTTPS, negociable vía meta-protocolo
Modelo de identidad	Identidad del servidor implícita (configurada por el host)	Agent Cards (JSON auto-publicado)	W3C DIDs (`did:wba`)
Formato de datos	JSON-RPC 2.0	JSON-RPC 2.0 con Parts (texto, archivos, estructurado)	JSON-LD (semántico, datos enlazados)
Descubrimiento	Configuración manual o consulta de registro	`/.well-known/agent-card.json`	Resolución DID + indexación descentralizada
Gobernanza	AAIF / Linux Foundation	AAIF / Linux Foundation	W3C Community Group (independiente)
Versión de la spec	2025-11-25	v1.0.0	Fase de libro blanco
Madurez	Producción (97M+ descargas mensuales del SDK)	Producción (v1.0.0, SDKs de grandes proveedores)	Desarrollo temprano (sin SDKs de producción)
Caso de uso	Dar a tu agente acceso a bases de datos, APIs, archivos	Hacer que tu agente delegue trabajo a agentes especializados	Que los agentes se encuentren en internet abierto

¿Cómo funcionan estos protocolos juntos?

Estos protocolos no son alternativas. Son capas. Veamos un ejemplo concreto.

Supongamos que ejecutas un agente de programación en tu VPS. Necesita:

Leer archivos de tu repositorio Git
Consultar la base de datos de tu proyecto para información de esquema
Pedir a un agente de revisión separado que compruebe su trabajo
Encontrar un agente de despliegue gestionado por el equipo de infraestructura de tu cliente

Los protocolos se apilan así:

┌─────────────────────────────────────────────────────────┐
│                    Tu VPS                                │
│                                                         │
│  ┌──────────────┐    MCP     ┌───────────────────────┐  │
│  │              │◄──────────►│ MCP Server: Git tools  │  │
│  │  Agente de   │            └───────────────────────┘  │
│  │  programa-   │    MCP     ┌───────────────────────┐  │
│  │  ción        │◄──────────►│ MCP Server: DB schema  │  │
│  │  (Host)      │            └───────────────────────┘  │
│  │              │                                       │
│  │              │    A2A     ┌───────────────────────┐  │
│  │              │───────────►│ Review Agent (A2A)     │  │
│  └──────┬───────┘            └───────────────────────┘  │
│         │                                               │
└─────────┼───────────────────────────────────────────────┘
          │
          │  ANP (descubrimiento entre redes)
          ▼
┌──────────────────────────┐
│ Agente de despliegue del  │
│ cliente (descubierto vía  │
│ resolución DID)           │
└──────────────────────────┘

Capa 1 (MCP): El agente de programación usa clientes MCP para conectarse a servidores MCP locales para operaciones Git y consultas a la base de datos. Son integraciones de herramientas. El agente llama funciones y lee datos.

Capa 2 (A2A): El agente de programación delega la revisión de código a un agente de revisión separado en el mismo servidor (u otro). Envía una tarea vía A2A, el agente de revisión trabaja de forma asíncrona y hace streaming de los resultados. El agente de programación no sabe qué modelo o framework usa el agente de revisión.

Capa 3 (ANP): El agente de programación necesita encontrar un agente de despliegue con el que nunca ha interactuado, gestionado por otra organización. El descubrimiento basado en DID de ANP localiza al agente, verifica su identidad y negocia un protocolo de comunicación.

Para la mayoría de configuraciones autoalojadas hoy, MCP es suficiente. Añade A2A cuando tengas varios agentes especializados que necesiten colaborar. ANP no es útil en producción todavía, pero importará cuando los ecosistemas de agentes crucen fronteras organizacionales.

¿Qué protocolo deberías usar?

Empieza con el protocolo más simple que resuelva tu problema. Añade capas solo cuando llegues a un límite.

Guía de decisión:

¿Tu agente necesita acceder a herramientas, bases de datos o APIs? Sí → Implementa MCP. Construye o instala servidores MCP para tus fuentes de datos. Esto cubre el 80 % de las necesidades de integración de agentes.
¿Tienes varios agentes que necesitan delegarse tareas mutuamente? Sí → Añade A2A. Publica Agent Cards para cada agente. Usa A2A para delegación de tareas y streaming de resultados. No → No necesitas A2A. Si un agente llama APIs a través de MCP, es suficiente.
¿Tus agentes necesitan descubrir agentes desconocidos más allá de fronteras organizacionales? Sí → Evalúa ANP cuando haya SDKs de producción disponibles. Hoy, lo resolverías con un registro manual o un directorio A2A compartido. No → Ignora ANP por ahora.

Patrones habituales:

Configuración	Protocolos necesarios
Agente único + herramientas (la mayoría de proyectos)	Solo MCP
Varios agentes especializados en un servidor	MCP + A2A
Colaboración entre organizaciones	MCP + A2A + ANP (cuando madure)
Marketplace de agentes / descubrimiento abierto	A2A + ANP

Si estás empezando con agentes IA en un VPS, empieza con MCP. Conecta un agente a una herramienta. Haz que funcione. Luego escala la arquitectura según crezcan tus necesidades.

¿Cuáles son los riesgos de seguridad de cada protocolo?

Cada protocolo abre una superficie de ataque diferente. Si alojas agentes tú mismo, estas son las amenazas que importan.

Protocolo	Amenaza	Consecuencia	Mitigación
MCP	Server-Side Request Forgery (SSRF)	Un prompt malicioso engaña al agente para que llame a una herramienta MCP que hace peticiones a servicios internos (endpoints de metadatos, bases de datos, paneles de administración).	Ejecuta servidores MCP en espacios de red aislados. Restringe conexiones salientes con reglas de firewall. Valida las entradas de herramientas en el servidor.
MCP	Descripciones de herramientas no fiables	Las anotaciones de herramientas MCP (descripciones, esquemas de parámetros) vienen del servidor. Un servidor comprometido puede mentir sobre lo que hace una herramienta para manipular al LLM.	Conecta solo servidores MCP que controles o en los que confíes. Revisa las descripciones. La spec de MCP marca explícitamente las anotaciones de herramientas como no fiables.
A2A	Suplantación de agente	Sin Agent Cards firmadas, un atacante puede publicar una Agent Card falsa en una URL conocida e interceptar tareas destinadas a un agente legítimo.	Usa la firma digital de Agent Cards de A2A (añadida en v0.3). Verifica firmas antes de enviar tareas. Fija los endpoints de agentes conocidos.
A2A	Exfiltración de datos de tareas	Las tareas pueden contener datos sensibles (código, credenciales, lógica de negocio). Si el agente remoto está comprometido, esos datos se filtran.	Cifra datos sensibles a nivel de aplicación. Usa TLS mutuo entre agentes. Minimiza los datos enviados en las tareas.
ANP	Arranque de confianza DID	El método `did:wba` depende de documentos DID alojados en HTTPS. Si un dominio está comprometido, todas las identidades de agentes en ese dominio están comprometidas.	Usa dominios separados para identidad de agentes. Monitoriza cambios en documentos DID. Implementa fijación de documentos DID para agentes conocidos.
ANP	Abuso del meta-protocolo	La capa de negociación podría explotarse para engañar a un agente y que use un protocolo de comunicación inseguro o malicioso.	Restringe la negociación del meta-protocolo a una lista blanca de protocolos conocidos. Registra y audita todas las negociaciones de protocolo.

Para una guía completa sobre cómo proteger tu servidor de agentes, consulta .

¿Hacia dónde va la gobernanza?

Tanto MCP como A2A están bajo la Agentic AI Foundation (AAIF), parte de la Linux Foundation. La AAIF fue establecida en diciembre de 2025 por tres cofundadores: Anthropic, OpenAI y Block. Google, Microsoft, AWS, Bloomberg y Cloudflare se unieron como miembros platinum. Ningún proveedor individual controla la dirección del protocolo.

La AAIF también aloja goose (el framework de agentes open source de Block) y AGENTS.md (el estándar de OpenAI para dar a los agentes IA orientación específica por proyecto).

ANP se gobierna de forma independiente a través de un W3C Community Group. No forma parte de la AAIF. Que ANP se una a la AAIF o permanezca independiente afectará su trayectoria de adopción.

La separación de gobernanza importa por una razón práctica: MCP y A2A evolucionarán juntos bajo dirección coordinada. ANP evolucionará en su propio calendario. Si haces apuestas arquitectónicas, MCP y A2A conllevan menor riesgo de gobernanza.

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproducción, republicación o redistribución sin permiso escrito está prohibida.