A2A: permite que los agentes de IA llamen a tu sitio
Publicado:
Un agente de IA acaba de validar este sitio sin abrir un navegador, hacer clic en ningún botón ni hacer scraping de ninguna página — leyó un pequeño archivo JSON, envió una solicitud tipada y recibió un resultado estructurado. Ese intercambio es A2A, y cualquier sitio web puede ofrecerlo.
Qué es A2A
A2A (Agent2Agent) es un protocolo abierto — actualmente bajo la Linux Foundation — que permite que los agentes de IA se descubran e invoquen mutuamente a través de HTTP simple. Piénsalo como el equivalente agente-a-agente de una API pública: en lugar de que un humano lea tu documentación y escriba una integración, otro agente lee una descripción en formato máquina de lo que hace tu servicio y lo llama directamente.
Tiene dos partes: un documento de descubrimiento (la tarjeta de agente) y un endpoint invocable (la habilidad).
1. La tarjeta de agente — descubrimiento
Publicas un archivo JSON en /.well-known/agent-card.json que describe quién eres y qué puedes hacer. Los campos obligatorios son name, description, version, url (tu endpoint A2A) y al menos una skill:
{
"protocolVersion": "0.3.0",
"name": "llms.txt Validator",
"description": "Validate a website's llms.txt and return a score with findings.",
"url": "https://llms-txt-validator.dev/a2a",
"skills": [{ "id": "validate_llms_txt", "name": "Validate llms.txt",
"description": "Given a domain or URL, fetch and validate its llms.txt." }]
}
2. El endpoint — una habilidad invocable
El url de la tarjeta apunta a un endpoint JSON-RPC 2.0. Un agente llama al método message/send con un mensaje; tú realizas el trabajo y devuelves una Task. Aquí hay una llamada real a nuestro agente:
POST /a2a
{ "jsonrpc": "2.0", "id": "1", "method": "message/send",
"params": { "message": { "role": "user",
"parts": [{ "kind": "text", "text": "validate llmstxt.org" }] } } }
…y la respuesta — una tarea completada que contiene un resumen legible por humanos y datos estructurados:
{ "result": { "kind": "task", "status": { "state": "completed" },
"artifacts": [{ "parts": [
{ "kind": "text", "text": "Validated llmstxt.org: score 100/100..." },
{ "kind": "data", "data": { "ok": true, "report": { "scores": { "overall": 100 } } } }
] }] } }
Sin navegador, sin análisis de HTML — el agente obtiene exactamente los datos que solicitó.
A2A vs WebMCP vs MCP
- A2A — agentes en red que llaman a tu servicio vía HTTP (orquestadores, otros agentes). Esta página.
- WebMCP — un agente que se ejecuta dentro del navegador e invoca herramientas en tu página abierta.
- MCP — conecta herramientas a un único modelo o aplicación, generalmente de forma local.
Son complementarios: A2A llega a agentes en red, WebMCP llega a los que están en el navegador. Consulta cómo encajan los tres.
Cómo cualquier sitio puede añadir uno
No necesitas implementar todo el protocolo para empezar — elige una cosa real que haga tu servicio:
- Sirve una tarjeta de agente válida en
/.well-known/agent-card.jsoncon una habilidad. - Implementa el método sincrónico
message/sendque envuelva esa capacidad, y devuelve unaTaskcompletada con el resultado como artefacto. - El streaming, el historial de tareas y las notificaciones push son opcionales — establece
capabilities.streamingen false y añádelos solo cuando los necesites.
La única regla: respalda la tarjeta con un endpoint real
La tarjeta es un contrato, no una metaetiqueta. Si publicas una tarjeta cuyo url no responde realmente a message/send, cada agente que confíe en ella llegará a un callejón sin salida. Expón A2A solo para las capacidades que realmente puedes servir — así es como construimos la nuestra, y por eso nuestro propio informe marca la señal como presente solo cuando un endpoint funcional la respalda. ¿Quieres verlo en vivo? Consulta nuestra tarjeta de agente.