MCP, A2A y tool calling: los protocolos de los agentes explicados
El protocolo A2A organiza los intercambios entre agentes independientes; MCP ofrece una interfaz común para conectar una aplicación de IA con herramientas y datos. El tool calling, o llamada a herramientas, permite al modelo solicitar una operación estructurada que ejecutará la aplicación o un servicio. Estos mecanismos pueden intervenir en una misma tarea, cada uno en una parte distinta del proceso.
Conexiones que responden a necesidades diferentes
Un agente no accede por sí solo a sus archivos ni a su programa de facturación. Su aplicación debe presentarle las capacidades disponibles, transmitir sus solicitudes y recoger los resultados. Cuando recurre a otro agente, también debe gestionar la relación con un sistema que tiene su propio funcionamiento.
Los términos pueden confundirse porque todos se refieren a intercambios. Sin embargo, el tool calling es un mecanismo que ofrecen las interfaces de los modelos, con formatos propios de cada proveedor. MCP y A2A definen intercambios estandarizados entre programas. La tabla permite situar sus responsabilidades sin presentarlos como soluciones rivales.
| Aspecto | Tool calling | MCP | A2A |
|---|---|---|---|
| Relación que organiza | Modelo y entorno de ejecución | Aplicación cliente y servidor de capacidades | Cliente y agente remoto |
| Contenido del intercambio | Solicitud de una operación y sus argumentos | Herramientas, datos y plantillas de instrucciones | Mensajes, tareas y resultados |
| Descubrimiento | Funciones presentadas al modelo | Capacidades expuestas por el servidor | Capacidades descritas en una Agent Card |
| Responsabilidad principal | Formular una llamada que pueda procesarse | Permitir reutilizar una integración | Organizar la colaboración entre sistemas |
La documentación oficial describe A2A y MCP como complementarios. La distinción se refiere a la interfaz que se ofrece: un servicio complejo puede presentarse como una herramienta, y un agente remoto puede utilizar herramientas a su vez.
Para entender las bases del ciclo que selecciona y encadena estas operaciones, el artículo Agente de IA o chatbot: ¿cuál es la diferencia? explica el papel de la aplicación que rodea al modelo.
Tool calling: solicitar una operación concreta
La llamada a herramientas empieza con una descripción: el nombre de la función, su finalidad y los parámetros que acepta. El modelo recibe esa descripción junto con la petición del usuario. A partir de ahí, puede generar una llamada estructurada en lugar de una respuesta destinada a la lectura.
En una aplicación de facturación ficticia, podría solicitar la búsqueda de facturas de un cliente determinado. El programa comprueba los parámetros, aplica los permisos, consulta el sistema de gestión y devuelve el resultado. Después, el modelo puede explicar ese resultado o proponer otra acción.
Esta separación es esencial: generar una llamada no significa haberla ejecutado. La documentación de Anthropic sobre el uso de herramientas distingue entre las herramientas que ejecuta la aplicación y las que se ejecutan en la infraestructura del proveedor. Por eso hay que identificar dónde se realiza cada operación.
Un esquema de parámetros ayuda a obtener una solicitud que el programa pueda procesar. No garantiza que se haya elegido al cliente correcto, que el importe esté justificado o que el usuario haya pedido esa acción. Esas comprobaciones también corresponden al software y a las reglas del negocio.
Si una aplicación se limita a unas pocas funciones internas, puede bastar con declararlas directamente. Incorporar un protocolo de conexión resulta útil cuando se necesitan compartir las mismas capacidades con varias aplicaciones, mantener su descubrimiento o gestionar su ejecución por separado del código del asistente.
MCP: una interfaz común para acceder a capacidades externas
El Model Context Protocol distingue entre la aplicación anfitriona, el cliente que se comunica y el servidor que expone capacidades. Este último puede ejecutarse en su equipo o de forma remota. Aquí, la palabra «servidor» designa un programa y no obliga a comprar una máquina dedicada.
Según la arquitectura oficial de MCP, la aplicación anfitriona coordina sus clientes, cada uno asociado a un servidor. Los intercambios locales pueden realizarse a través de la entrada y la salida estándar del proceso; las conexiones remotas pueden utilizar Streamable HTTP.
El beneficio que se busca es poder reutilizar la interfaz. Un servicio puede exponer sus capacidades mediante MCP en lugar de mantener una integración específica para cada aplicación. Esto no elimina la configuración ni las diferencias de compatibilidad entre clientes.
La documentación distingue las capacidades que ofrecen los servidores MCP:
- las herramientas, que realizan una operación o recuperan información;
- los recursos, que proporcionan contenido para utilizarlo como contexto;
- los prompts, que ofrecen plantillas de instrucciones reutilizables.
La aplicación puede presentar al modelo las herramientas descubiertas, recibir su solicitud mediante tool calling y transmitir después la operación al servidor MCP. En ese caso, el protocolo de conexión y el mecanismo de decisión trabajan juntos.
Por tanto, un servidor MCP no necesariamente elige un objetivo ni lleva a cabo una tarea de forma autónoma. Para revisar las integraciones disponibles, consulte las fichas de servidores MCP; la guía Elegir un servidor MCP detalla los criterios de confianza y permisos.
El protocolo A2A: comunicarse con otro agente
A2A, abreviatura de Agent2Agent, está dirigido a sistemas que necesitan comunicarse con un agente independiente. El cliente le envía una solicitud sin tener que conocer su modelo, su memoria ni sus herramientas internas. Esta separación permite, entre otras cosas, mantener arquitecturas diferentes en ambos sistemas.
Los conceptos fundamentales de A2A distinguen entre el cliente que inicia el intercambio y el agente remoto que procesa la solicitud. Este último expone una Agent Card: una descripción de su identidad, sus competencias y sus capacidades de interacción.
Esta tarjeta ayuda a determinar si el servicio parece adecuado para una tarea. No es una certificación de calidad. Las competencias declaradas deben evaluarse con solicitudes representativas y criterios explícitos sobre el resultado esperado.
A2A puede utilizarse para pedir un análisis a un sistema especializado y continuar el intercambio si falta información. Quien hace la solicitud no necesita indicar cada llamada técnica. Sí debe precisar el resultado que espera y las restricciones que deben respetarse.
El término protocolo A2A no engloba cualquier conversación entre agentes. Los subagentes que pertenecen a una misma aplicación pueden comunicarse mediante mecanismos internos. A2A aporta un acuerdo sobre cómo intercambiar información cuando la interacción cruza la frontera entre sistemas.
Del mismo modo, hacer que un agente sea accesible mediante A2A no demuestra que sepa colaborar de forma útil. Su utilidad depende de cómo se reparta el trabajo: una responsabilidad clara y un entregable verificable son más fáciles de aprovechar que una delegación imprecisa.
Seguimiento de tareas y entregables identificables
Una solicitud enviada a un agente remoto puede requerir varios intercambios. El ciclo de vida de las tareas A2A contempla una respuesta inmediata mediante un mensaje o una tarea con estado. Esta puede avanzar, solicitar información adicional, fallar o finalizar.
La aplicación cliente debe interpretar ese estado. Una tarea que espera una aclaración no debe mostrarse como terminada; si una tarea falla, no debe generar una respuesta alternativa sin avisar. Por ello, la interfaz de usuario también forma parte de la fiabilidad del conjunto.
La especificación de A2A distingue los mensajes de comunicación de los artifacts, es decir, los entregables asociados a una tarea. También contempla diferentes formas de recibir actualizaciones, como las consultas periódicas, el flujo de eventos y las notificaciones, según las capacidades anunciadas.
En su aplicación, esta distinción permite separar un comentario sobre el avance del documento final que se va a utilizar. Aun así, hay que definir qué condiciones debe cumplir ese documento para ser aceptable: formato esperado, procedencia de los datos, información que falta y comprobaciones necesarias.
Que el estado técnico indique que la tarea ha terminado significa que el procesamiento anunciado ha finalizado. No garantiza la exactitud del contenido generado. La guía sobre sistemas multiagente ayuda a evaluar el interés de esta delegación y la carga de coordinación que añade.
Ejemplo: preparar recordatorios de pago
Veamos un escenario ficticio: usted pide preparar recordatorios para las facturas pendientes de pago, con su aprobación antes del envío. La aplicación principal debe consultar los datos contables, gestionar los casos particulares y presentarle los borradores.
Los mecanismos pueden encadenarse de la siguiente manera:
- La aplicación descubre, mediante MCP, las herramientas autorizadas para consultar facturas.
- El modelo solicita esa consulta mediante tool calling; la aplicación transmite la operación y recupera los datos.
- Si un agente especializado debe examinar los casos en disputa, la aplicación le encarga ese análisis mediante A2A.
- La aplicación sigue la tarea remota, recupera su entregable y prepara los recordatorios para que usted los revise.
Este ejemplo ilustra una arquitectura posible, no una integración lista para usar. Cada conexión exige compatibilidad efectiva, permisos adecuados y un acuerdo sobre los datos que se intercambian.
También muestra dónde deben situarse los controles. Leer una factura, transmitir su contenido a un servicio remoto y enviar una comunicación son acciones diferentes. El permiso de consulta no debería interpretarse como una autorización general para compartir información.
Si las reglas de los recordatorios son fijas, una automatización convencional puede ser suficiente. La elección entre plataformas requiere otro análisis, que se aborda, entre otros contenidos, en la comparativa n8n vs Make. El protocolo no sustituye esa decisión de arquitectura.
Compatibilidad y seguridad: comprobar el proceso completo
La mención «compatible con MCP» o «compatible con A2A» no describe una integración completa. Compruebe qué capacidades admite realmente, cómo funciona la autenticación, cómo se gestionan los errores y cómo se presentan los resultados. Un intercambio aceptado técnicamente puede seguir siendo inservible para su proceso.
Las buenas prácticas de seguridad de MCP abordan, entre otros, los riesgos relacionados con los servidores locales, los intermediarios de autorización y la transmisión de tokens de acceso. Conectar un servidor local equivale a autorizar la ejecución de un programa: conviene examinar su procedencia y sus permisos.
Para delegar trabajo en un servicio remoto, precise qué datos pueden salir de la aplicación y con qué identidad se realizarán las acciones. El servicio receptor debe aplicar sus propios controles; la solicitud del modelo no constituye una prueba de autorización.
Los contenidos recibidos también siguen siendo datos externos. Un documento, la descripción de una herramienta o un entregable pueden contener instrucciones engañosas. El artículo sobre la seguridad de las integraciones MCP y las skills detalla las comprobaciones que deben hacerse antes de la instalación.
Antes de ampliar los accesos, pruebe un proceso completo que incluya un error, una denegación y una interrupción. Usted debe poder entender qué se ha solicitado, ejecutado y transmitido. Un protocolo estandariza los intercambios; el control de las acciones depende de la aplicación que las autoriza y supervisa.
Preguntas frecuentes
¿Qué significa A2A en los agentes de IA?
A2A significa Agent2Agent. Este estándar describe los intercambios entre sistemas de agentes independientes, aunque su funcionamiento interno no sea público. Para integrar estos sistemas, deben admitirse las interfaces y capacidades necesarias para el intercambio.
¿Se puede usar MCP sin el protocolo A2A?
Sí: un asistente conectado a herramientas no necesita delegar trabajo en otro agente. A2A resulta pertinente cuando un sistema debe comunicarse con un servicio de agentes independiente. Por tanto, la cantidad de herramientas disponibles no basta para justificar su incorporación.
¿El tool calling necesita un servidor MCP?
No: una aplicación puede declarar sus funciones directamente al modelo y ejecutar las llamadas que reciba. MCP ofrece una interfaz común para descubrir y utilizar capacidades externas. La elección depende, entre otros factores, de si esas conexiones deben reutilizarse en varias aplicaciones.
¿Un agente compatible con A2A puede acceder a todas mis herramientas?
La compatibilidad no le concede acceso general a sus cuentas. Los permisos dependen del servicio, de la identidad utilizada y de los controles aplicados en el servidor. También hay que revisar los datos incluidos en cada delegación.