MCP frente a A2A: cómo se utilizan realmente los protocolos modelo en 2025

MCP (Model Context Protocol) y A2A (Agent-to-Agent) están remodelando rápidamente nuestros supuestos tradicionales sobre arquitectura de software. Tanto si dirige la estrategia como si construye soluciones, se las explicaremos con claridad para evitar los errores habituales que se cometen al integrar tecnologías emergentes.

Al final de este artículo, lo entenderá:

• Qué es el MCP y por qué utilizarlo
• Qué es el A2A y dónde encaja en su pila
• Cuándo utilizar cada protocolo
• Por qué es probable que utilice ambos en el futuro

¿Qué son MCP y A2A y por qué deberían importarle?

Estamos en la vanguardia de uno de los mayores cambios de paradigma de la historia moderna. Casi todo el mundo utiliza a diario la inteligencia artificial en uno u otro contexto. En flujos de trabajo y arquitectura, un modelo utilizado para realizar una tarea se denomina “agente”.

En el centro de la mayor parte de su uso actual se encuentra el Protocolo de Contexto de Modelo (MCP). Agent-to-Agent (A2A) es más un conjunto de características emergentes que un protocolo claramente definido.

• MCP: Se utiliza para gestionar tanto el contexto como el estado interno del modelo. Probablemente interactúes con MCP todos los días. Modelos como Grok, ChatGPT y CoPilot utilizan MCP para gestionar el contexto y las tareas con fines generales. Cuando crees tu propio agente, probablemente escribirás un MCP personalizado.
• A2A: Cuando dos o más modelos hablan entre sí, se trata de un proceso Agente-Agente. Cada agente sigue su propio MCP. Su proceso de comunicación se denomina A2A. Es como el lenguaje hablado y escrito entre humanos.

Modelo Contexto Protocolo-El cerebro

Se puede pensar en MCP casi como el “cerebro” de la máquina. La MCP abarca todos los procesos internos de una tarea, desde la interpretación del lenguaje hasta la finalización de la tarea.

En X, puedes encontrar un sinfín de mensajes en los que los usuarios responden “@grok”, seguido de una pregunta o afirmación. Grok interpreta la pregunta del usuario y responde con un mensaje relacionado con el tema. Se trata de un MCP de manual que responde a un caso de uso real.

1. Enrutamiento de consultas

Nuestro primer paso es el “enrutamiento de consultas”. Cuando dices, “@grok, ¿puedes comprobar los hechos de este post?”, Grok realizará una búsqueda y leerá el texto relevante. Si dices, “@grok, por favor describe este post como una imagen”, Grok enrutará la petición a una Aurora diferente. Puedes leer más sobre Aurora aquí.

• Tú haces la consulta inicial.
• El agente interpreta la consulta y elige un modelo para gestionarla.

2. Recogida de herramientas

Una vez que la tarea se ha pasado a un modelo de IA específico, el modelo selecciona las herramientas para completar la tarea dada. Si tuvieras que colgar una estantería, probablemente cogerías un martillo y clavos, o un taladro y tornillos: eso es exactamente lo que hace el modelo.

Estas herramientas pueden ser un motor de búsqueda, una calculadora, un intérprete de Python… literalmente cualquier cosa. Si se le pidiera a Grok que comprobara los hechos, probablemente elegiría dos herramientas.

• Motor de búsqueda: El modelo realiza una búsqueda y evalúa los resultados “fiables”. No estoy apoyando los resultados de confianza de Grok aquí, sólo se están utilizando para el contexto.
• Calculadora: Si el post parece sobreexagerar o infraexagerar, tal vez las estadísticas COVID, Grok debe utilizar una calculadora para sumar los números tanto de la búsqueda como del post del usuario.

3. Traspaso de servidores

Una vez que el modelo ha estructurado la tarea y elegido sus herramientas, tiene que transmitirla. En primer lugar, indica al motor de búsqueda la consulta que debe realizar. Una vez que tiene los números, envía una serie de cálculos a una calculadora.

El término “servidor” se utiliza aquí en sentido amplio. Dependiendo de su modelo y configuración, este “servidor”, podría ser algo que se ejecuta dentro de un centro de datos, o incluso podría estar funcionando en http://localhost:6000-orcualquier otro puerto para el caso. El punto es simple: las herramientas escuchan los trabajos, y el modelo envía esos trabajos a las herramientas.

• Las herramientas escuchan en los puertos: El modelo entrega el trabajo a la herramienta “servidor” correcta. Hace una petición HTTP al servidor y espera una respuesta. Básicamente, Grok envía “1+1=?” al servidor.
• Elservidor envía una respuesta: El servidor responde con los datos del trabajo completado. El servidor podría decir “1+1=2”. Grok puede ahora tomar la respuesta y utilizarla en el contexto correcto.

4. Puntos de control (opcionalmente humanos)

Antes de enviar la respuesta al agente, hay que comprobar los resultados del modelo. Puede que no te des cuenta, pero los modelos de hoy en día siguen presentando resultados sesgados y erróneos. Para evitar una respuesta incorrecta como “1+1=3” o “1+1=ragebait”, la salida pasa por uno o varios puntos de comprobación.

Dependiendo del contexto de la tarea, estos puntos de control podrían ser humanos, o podrían ser un modelo ejecutando el mismo trabajo. La cuestión es sencilla: no dejes que el usuario reciba resultados erróneos.

• El punto de control: Un humano o un modelo comprueba dos veces el resultado de la tarea. Así se evita que el usuario reciba resultados tontos o embarazosos.
• Corrección: Si el resultado es incorrecto, el agente debe volver a intentar el trabajo: puede utilizar el mismo modelo o pasar el trabajo a otro diferente.
• El resultado real: Una vez comprobada la salida, Grok la publica en una respuesta a la persona que utilizó “@grok”.

Protocolo agente-agente: comunicación entre cerebros

Si la MCP es la función cerebral global del agente, la A2A es la forma en que múltiples cerebros hablan entre sí. En la vida real, varios agentes ya hablan entre sí. Imagina que estás en una conversación con ChatGPT.

ChatGPT y tú estáis hablando de gatos. Es una conversación larga y va de un lado a otro. Gatos pequeños, gatos grandes, gatos inteligentes… Entonces, decides hablarle a ChatGPT de tu gato. Quieres una foto ridícula de tu gato buscando la dominación del mundo (porque en el fondo todos los gatos quieren esto).

ChatGPT por sí mismo no puede crear la imagen. ChatGPT subcontrata esta tarea a DALL-E del mismo modo que Grok utilizaría Aurora. El agente que ejecuta ChatGPT hablará con el agente que ejecuta DALL-E para realizar la tarea.

Tarjeta de Agente: El README de su agente

Las tarjetas de agente se utilizan para mostrar a los demás lo que su agente de IA puede hacer. Esto debería mostrar a la gente cómo conectarse a él y qué tipos de resultados esperar de él. No necesitas entrar en detalles aquí. No estás guiando a los usuarios a través de tu código, estás explicando con ejemplos de uso ultra-básicos y su salida esperada. Si alguna vez has leído la documentación de la API, sabrás lo que es apropiado aquí y lo que no lo es.

• Conexión: Muestre exactamente cómo conectarse de forma segura al agente. Si está demostrando una API REST, utilice ejemplos HTTPS con el dominio real, no HTTP desnudo en un host local. Si su agente se gestiona mediante SDK, muestre cómo conectarse utilizando el SDK.
• Uso sencillo: Para las API REST, esto es bastante estándar: puntos finales y salida. Si se utiliza un SDK, mostrar las clases básicas y métodos involucrados.
• Salida de ejemplo: Debajo de cada fragmento de uso, debe mostrar otro fragmento con salida de ejemplo.

Cuando escriba una aplicación A2A, utilizará la tarjeta de agente para conectar varios agentes entre sí. Al crear tus propios agentes, otros los utilizarán a través de la tarjeta de agente.

Trata a la gente como quieres que te traten a ti.

Sistema de tareas: Cómo se crean y realizan las tareas

Su sistema de tareas es básicamente una simple aplicación CRUD (Crear, Leer, Actualizar, Eliminar). Un usuario debe ser capaz de crear una tarea. Debe poder leer su estado. Tanto el usuario como el agente necesitan actualizar la tarea. En este caso, la eliminación es más un método de buenas prácticas: si creas una aplicación de tareas que nunca deja de crecer, es un desperdicio.

• Crear: Los usuarios (otros agentes en este caso) deben poder crear una nueva tarea. El agente de ChatGPT le dice a DALL-E que necesitamos un gato malvado decidido a dominar el mundo.
• Leer: Los usuarios (u otros agentes) necesitan poder comprobar el estado de una tarea. Cuando ChatGPT dice “Creando Imagen”, el estado es “en progreso”. Los agentes siempre deben poder leer y transmitir el estado de una tarea determinada.
• Actualización: Olvidaste decirle a ChatGPT que querías una pajarita en tu gato. Deberías poder actualizar la solicitud para obtener una imagen mejor. Además, DALL-E debería actualizar el estado de la tarea mientras ChatGPT la espera.
• Borrar: Las empresas ignoran cada vez más esta función básica, centrándose más en los lagos de datos que en la eficiencia. Tu agente debería poder eliminar una tarea: conservar tareas canceladas no solo es inútil, sino que además desperdicia almacenamiento sin motivo.

Mensajería segura

Los mensajes entre agentes deben ser seguros. Demos un paso atrás en la informática general y pensemos en las conexiones SSL y HTTPS. Cuando envías una petición a través de HTTPS/SSL, el cuerpo de la petición está encriptado. Sólo el servidor puede leerlo. Cuando el servidor envía su respuesta, está cifrada para que sólo tu navegador pueda leerla.

Los agentes deben seguir este mismo principio. Cuando se trabaja con múltiples agentes de IA (que probablemente sustituyan una tarea totalmente humana), a veces puede estar implicada información sensible. Estos agentes también deberían utilizar un protocolo de cifrado.

• Cifrado: Cuando los agentes se comunican, deben hacerlo cifrados de extremo a extremo. Cualquiera que intercepte el mensaje solo podrá ver basura desordenada.
• Autenticación: Con técnicas de autenticación adecuadas, como las firmas digitales, los agentes pueden saber con quién están hablando. Cuando se vincula a una huella dactilar específica, la información de las tareas se limita a quienes tienen el acceso adecuado.

Soporte de larga duración para trabajos largos

Algunas tareas no se completan inmediatamente. A veces tardan horas, incluso días. Cuando esto ocurre, su agente debe ser comunicativo. Especialmente cuando un trabajo implica a varios agentes, el usuario debe recibir actualizaciones de estado de los agentes.

• Actualizaciones en tiempo real: Sus agentes deben actualizar su estado en tiempo real. Esto permite al usuario comprobar el estado cuando le convenga.
• Notificaciones y correo electrónico: Sus agentes también deben enviar actualizaciones de estado de forma incremental. Cuando se complete una tarea, envía un correo electrónico o una notificación push.

Sus agentes deben mantener informados a los usuarios sin saturarlos. Sus usuarios utilizan su A2A por comodidad: haga que las tareas de larga duración sean lo más cómodas posible.

Comunicación multimodal

A menudo, cuando los procesos A2A se ocupan de tareas multimodales. Piense en el ejemplo de ChatGPT y DALL-E. ChatGPT se encarga del chat de texto propiamente dicho, mientras que DALL-E se ocupa de la creación de imágenes.

• Texto libre y lógica: A menudo a cargo de un LLM especializado en Procesamiento del Lenguaje Natural.
• Generación de imagen y vídeo: De estas tareas se encargan otros modelos especializados, como DALL-E y Sora.

Las tareas suelen requerir formatos de datos multimodales. Cuando se trate de estas tareas multimodales, su protocolo A2A deberá dividirlas entre los modelos apropiados.

¿Cuándo se debe utilizar cada protocolo?

Cada uno de estos protocolos está diseñado para manejar diferentes escenarios. MCP se ocupa de las partes internas de un agente: su cerebro. A2A se utiliza para que varios agentes se comuniquen entre sí.

Conclusión: En el futuro, utilizará ambos

MCP y A2A no son normas competidoras, sino sistemas complementarios. MCP es la suma de los procesos internos de un agente. A2A dicta la comunicación entre agentes.

• MCP permite que su agente se comporte de forma inteligente.
• A2A permite a los agentes inteligentes hablar entre sí.

Si está entrenando sus propios modelos de IA, Bright Data ofrece conjuntos de datos personalizados con datos históricos para que su agente pueda detectar tendencias. ¿Necesita datos en tiempo real? Eche un vistazo a la API Scraper: obtengasus datos siempre que su agente lo necesite. para que su agente esté siempre preparado. Con Agent Browser, sus agentes pueden navegar por Internet como un humano, con integración de proxy y resolución de CAPTCHA.