MCP vs A2A: qué conecta cada protocolo y cuál necesitas

MCP y A2A no compiten. MCP conecta tu agente con herramientas y datos. A2A lo conecta con otro agente. Son dos capas del mismo sistema, y la pregunta no es cuál eliges, sino cuál te hace falta hoy.

Doy por hecho lo básico de MCP: un servidor expone tools, resources y prompts que tu agente llama como funciones. Si no, empieza por qué es MCP. Si lo comparas con una API REST o con function calling, MCP vs API; si se te mezcla con RAG, MCP vs RAG.

MCP vs A2A: la diferencia en una tabla

Lo que cambia es qué hay al otro lado del cable; la última fila es la que decide.

	MCP	A2A
Qué conecta	Un agente con herramientas y datos	Un agente con otro agente
Qué hay al otro lado	Un servidor MCP: una función que ejecutas y devuelve un resultado. No decide nada	Un sistema autónomo que razona y puede tardar horas
Quién publica el contrato	El servidor MCP, con los esquemas de sus tools	El agente remoto, en su Agent Card
Cómo lo encuentras	Lo configuras tú: comando, URL o fichero	En /.well-known/agent-card.json del otro dominio, o en un registro
Cuándo lo necesitas	Cuando tu agente ejecuta herramientas o toca datos de un sistema tuyo	Cuando el otro extremo no lo controlas tú

¿Qué es el protocolo A2A?

A2A (Agent2Agent) es un estándar abierto para que agentes autónomos de frameworks distintos se descubran, se deleguen tareas y se coordinen sin compartir su memoria interna, sus herramientas ni su lógica^[1]. Lo creó Google, lo donó a la Linux Foundation y desde agosto de 2026 es un proyecto de la Agentic AI Foundation, la misma que aloja MCP^[2]. Su comité técnico lo forman AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP y ServiceNow: ya no es cosa de Google.

Lo sostiene todo la Agent Card: un JSON publicado en https://{dominio-del-agente}/.well-known/agent-card.json con name, description, provider, la url del endpoint, las capacidades A2A (streaming, pushNotifications), los esquemas de autenticación y la lista de skills, cada una un AgentSkill con id, descripción y modos de entrada y salida^[3].

La especificación 1.0 define tres bindings de transporte (JSON-RPC 2.0, gRPC y HTTP+JSON/REST, más los propios funcionalmente equivalentes) y el streaming va sobre Server-Sent Events^[1]. Su vocabulario: la Task es la unidad de trabajo, con identificador propio, stateful y con ciclo de vida; el Message es comunicación con rol user o agent, compuesto de Parts (texto, fichero o JSON); el resultado es un Artifact^[1]. La diferencia práctica: una tool MCP va y vuelve, un Message abre una tarea que puede durar media hora y avisarte por push.

¿Cuándo necesito A2A y cuándo me sobra?

Si todo lo que hay al otro lado son herramientas que has escrito tú, A2A no te aporta nada. Un agente que consulta tu base de datos y llama a tu API de pedidos es MCP y punto. Los subagentes de tu orquestador tampoco lo necesitan: comparten proceso, despliegue y equipo, y un protocolo para no fiarse del otro solo añade latencia.

A2A importa cuando al otro lado hay un agente que no controlas: el de otro departamento, el de un proveedor, el de un cliente que no va a publicar su código. Ahí necesitas lo que estandariza A2A: descubrir qué sabe hacer el otro, autenticarte, mandarle trabajo que puede tardar y recibir el resultado sin acordar nada por email.

Los dos juntos en el mismo sistema

La documentación oficial lo resume bien: «MCP es vertical, profundiza un solo agente. A2A es horizontal, conecta agentes a través de esa frontera»^[4].

Un agente de compras habla MCP hacia dentro (un servidor con tu catálogo, otro con el stock del ERP) y publica hacia fuera una Agent Card con la skill solicitar-presupuesto. El agente de tu proveedor la lee, manda un Message, se abre una Task y el presupuesto llega como Artifact, sin tocar tu ERP. Las herramientas se quedan dentro; sale una capacidad.

Elegir la capa que resuelve cada problema, en vez de aplicar el protocolo de moda, se practica en el curso de patrones agénticos.

Fuentes

1. A2A Protocol Specification — Agent2Agent Project — definición de Task, Message, Part y Artifact, bindings de transporte y operaciones del protocolo.
2. A New Chapter for A2A: Joining the Agentic AI Foundation — entrada de A2A en la Agentic AI Foundation, agosto de 2026.
3. Agent Discovery — A2A Protocol — campos de la Agent Card, objetos AgentSkill y la ruta /.well-known/agent-card.json.
4. A2A and MCP — A2A Protocol — postura oficial sobre la complementariedad entre los dos protocolos.
5. Agent Communication Protocol — aviso oficial de que ACP pasa a formar parte de A2A bajo la Linux Foundation.
6. Agent Client Protocol — Zed — descripción del protocolo entre editores y agentes de programación.

Preguntas Frecuentes

¿A2A sustituye a MCP? ¿Necesito los dos?

No sustituye: la propia documentación de A2A los presenta como complementarios. Si tu agente solo toca herramientas y datos tuyos, MCP basta; en cuanto parte del trabajo la hace un agente de otro equipo o de otra empresa, quieres los dos, MCP hacia dentro y A2A hacia fuera.

¿Qué es una Agent Card?

Es el JSON donde un agente declara su endpoint, su autenticación y sus skills; los campos están arriba. Añado que /.well-known/agent-card.json no es la única vía: la especificación contempla registros intermedios y configuración directa entre sistemas acoplados.

¿A2A es solo de Google?

Lo creó Google, pero lo donó a la Linux Foundation; hoy lo gobierna, dentro de la Agentic AI Foundation, el comité técnico de ocho empresas listado arriba.

¿Y ACP? ¿Dónde encaja en la comparativa?

Hay dos cosas con ese nombre. El Agent Communication Protocol, el de agente a agente salido de BeeAI, ya no es alternativa: su web anuncia que pasa a A2A bajo la Linux Foundation^[5]. El Agent Client Protocol de Zed sigue vivo, pero conecta un editor con un agente de programación, no dos agentes entre sí^[6].