Tres siglas, tres problemas distintos
MCP, A2A y ACP aparecen juntas en casi cualquier conversación sobre agentes, y eso hace creer que compiten. No compiten: cubren tramos distintos del mismo recorrido. Confundirlos lleva a construir sobre el protocolo equivocado y a pagarlo en una reescritura.
La separación, en una línea: MCP conecta un agente con herramientas y datos; A2A y ACP conectan agentes entre sí.
MCP: el que ya ganó
El Model Context Protocol nació en Anthropic a finales de 2024 con un objetivo acotado: estandarizar cómo un modelo descubre y usa herramientas externas. En diciembre de 2025 pasó a la Agentic AI Foundation, bajo el paraguas de la Linux Foundation, dejando de ser el protocolo de un proveedor para volverse infraestructura compartida.
Para una empresa que decide hoy, lo que importa de esa historia es una sola cosa: hay soporte nativo en los asistentes y entornos de desarrollo de los principales proveedores. Un servidor MCP escrito una vez se consume desde clientes distintos sin reescribirlo, y eso es exactamente lo que se le pide a un estándar.
El modelo mental correcto es el de un adaptador:
Sin MCP Con MCP
Asistente A ── ERP Asistente A ─┐
Asistente A ── CRM │
Asistente B ── ERP Asistente B ─┼── Servidor MCP ── ERP
Asistente B ── CRM │ ── CRM
Asistente C ── ERP Asistente C ─┘ ── Facturación
N clientes x M sistemas N + M integraciones
A2A y ACP: agentes hablando con agentes
MCP no cubre que un agente le encargue trabajo a otro agente, sobre todo si el otro pertenece a otra organización y nadie quiere exponer sus herramientas internas. Ese es el terreno de A2A y protocolos afines: descubrir qué sabe hacer un agente ajeno, encargarle una tarea, seguir su avance y recibir el resultado, sin compartir el interior de la caja.
El estado de madurez, a octubre de 2026, es claramente distinto:
| Protocolo | Conecta | Madurez | Úsalo si… |
|---|---|---|---|
| MCP | Agente ↔ herramientas y datos | Alta, ampliamente adoptado | Necesitas que un asistente consulte o actúe sobre tus sistemas |
| A2A | Agente ↔ agente, entre organizaciones | En consolidación | Tienes un caso real de delegación entre partes distintas |
| ACP | Mensajería entre agentes | Emergente | Estás experimentando, no construyendo producción |
La recomendación práctica es poco emocionante y bastante sólida: adopta MCP hoy; sigue A2A de cerca y espera a tener un caso de uso que lo exija. La mayoría de los problemas que la gente quiere resolver con agentes hablando entre sí se resuelven mejor con un agente y buenas herramientas, por las razones que ya vimos en un agente o varios.
Un servidor MCP es una API, con todo lo que eso implica
El error más caro que vemos es tratar al servidor MCP como un script interno. No lo es: es una superficie de integración que un modelo va a invocar de forma autónoma. Merece el mismo tratamiento que cualquier API pública de la empresa.
- Autenticación y autorización por cliente. Quién se conecta y qué subconjunto de herramientas puede ver. La especificación de 2026 endureció precisamente esta parte.
- Permisos mínimos por herramienta. Si una herramienta solo debe consultar, que no exista el parámetro que borra. El modelo invocará lo que esté disponible.
- Descripciones escritas para el modelo. Una herramienta mal descrita no se usa, o se usa mal. Esta es la parte donde más se gana y la que menos atención recibe.
- Pocas herramientas, bien elegidas. Cuarenta herramientas casi idénticas confunden más de lo que aportan. Es preferible una operación bien pensada que seis variantes.
- Versionado. Cambiar un parámetro rompe a todos los clientes a la vez, y los clientes aquí son agentes que no leen notas de versión.
- Auditoría. Quién llamó a qué, con qué parámetros y qué devolvió. Es el registro que necesitarás el día que algo salga mal.
Lo que el protocolo no te da
Conviene ser explícito, porque se asume de más: MCP estandariza el transporte y el descubrimiento, no la seguridad de tu negocio. Que una herramienta se exponga siguiendo la especificación no la vuelve segura. Si el agente que la consume lee correos o páginas web, una inyección de prompts puede hacer que la invoque con parámetros elegidos por un tercero.
Dicho de otro modo: el protocolo resuelve la fontanería. Las decisiones sobre qué puede hacer el agente y qué requiere confirmación humana siguen siendo tuyas, y son las que determinan el daño posible.
Por dónde empezar
Un camino de bajo riesgo que funciona bien en empresas medianas:
- Semana 1: un servidor MCP de solo lectura sobre un sistema que ya tienes —consultar estado de pedidos, buscar un cliente, revisar stock—. Sin escrituras.
- Semana 2-3: conéctalo al asistente que el equipo ya usa y observa qué preguntan de verdad. Casi nunca es lo que se había supuesto.
- Después: agrega escrituras de una en una, cada una con su confirmación y su registro.
Lo valioso de empezar en solo lectura es que el peor caso es una respuesta equivocada, y eso permite aprender sobre el uso real sin apostar nada.
Conclusión
MCP es, a octubre de 2026, la apuesta segura para conectar agentes con sistemas internos: está en manos de una fundación neutral, lo soportan los principales clientes y evita el patrón de integrar cada asistente con cada sistema. A2A resuelve un problema distinto, real pero menos urgente para la mayoría de las empresas.
Si vas a exponer tus sistemas a un agente, el fondo del asunto está en cómo diseñar herramientas que un agente pueda usar bien y, antes de abrir escrituras, en tratar esas integraciones con criterio de API.