Dales a los agentes una herramienta para enviarte comentarios
Si publicas un servidor MCP, la mayoría de quienes lo usan no son personas. Un agente lee las descripciones de tus herramientas, elige una, envía una carga útil, recibe un resultado y decide qué hacer a continuación. Todo ese ciclo ocurre sin que nadie lo supervise.
Así que, cuando algo falla, nadie te lo cuenta. El agente lo intenta de nuevo, busca una alternativa o se rinde y le dice al usuario que no se puede completar la tarea. Tú no ves nada de eso.
La solución es sencilla: añade una herramienta más a tu MCP y deja que el agente te informe del problema.
Una herramienta y una descripción que indique cuándo usarla
La herramienta no modifica el producto. Recibe una descripción de lo que ha fallado y te la reenvía. Lo que hace que funcione es la descripción que lee el agente, porque es la única instrucción que recibe.
Esta es la que uso en AI Glot:
Usa esta herramienta mientras trabajas con AI Glot si una herramienta, respuesta,
un error o un flujo de trabajo de AI Glot se comporta de forma distinta a la
esperada, o si te gustaría que algo funcionara de otra manera. Llámala cuando el
problema esté claro. Describe la situación, lo que has observado y lo que debería
haber ocurrido. Si lo sabes, incluye la herramienta, operación de API o comando
de CLI relacionado, el modelo de IA y el entorno del agente. No incluyas claves de
API, tokens, URL firmadas ni el contenido completo de archivos. Esta herramienta
solo registra comentarios, no vuelve a intentarlo ni cambia tu traducción, y no
cuesta créditos.Hay tres frases que cumplen una función importante. «Cuando el problema esté claro» evita que se active ante el primer error transitorio. «No vuelve a intentarlo» evita que el agente recurra a ella como medida de recuperación cuando falla una llamada. «No cuesta créditos» importa porque los agentes desconfían de cualquier cosa que pueda gastar el dinero del usuario, y si no están seguros de una herramienta, no la usan.
- 1El agente tiene un problemaUn rechazo, algo inesperado, una herramienta que falta
- 2Llama a la herramienta de comentariosAún conserva todo el contexto
- 3Tu servidor añade lo que sabeEspacio de trabajo, interfaz, fecha y hora
- 4El informe llega donde tú quierasUn webhook, y luego ya es cosa tuya
Los campos
Aquí es donde reside la mayor parte del valor. Un cuadro de texto libre te dará un «no funcionó». Los campos con nombre te darán información sobre la que puedes actuar.
Esto es lo que solicita la herramienta de AI Glot, con los tres campos obligatorios al principio:
expected_solution es el campo que conservaría si solo pudiera tener uno. Un usuario te dice que algo está roto. Un agente te cuenta qué esperaba que hiciera la llamada, lo que permite comprobar directamente si la descripción de tu herramienta se corresponde con la herramienta.
Los tres campos opcionales existen porque «no lo adivines» es una instrucción que un agente seguirá de verdad. Prefiero dejar el campo vacío a rellenarlo con un nombre de modelo que parezca plausible. Cuando se rellenan, puedes filtrar por modelo y por entorno del agente, y un problema que solo ocurre en uno de ellos deja de parecer aleatorio.
Qué aspecto tiene un informe real
Este es uno real, tal como me llegó el 10 September:
Es un informe de error con una forma de reproducirlo, un diagnóstico y una solución propuesta, redactado por quien se topó con él, segundos después de que ocurriera. No se lo pedí ni pagué por ello.
Por qué esto es mejor que los comentarios que sueles recibir
No digo que los agentes sustituyan a los usuarios. Digo que este canal concreto tiene características que los comentarios de los usuarios no tienen.
Lo que te cuenta un usuarioHoras o días después
- Lo recuerda y reconstruye en parte
- Filtrado por lo que cree que merece la pena contar
- Suavizado, porque quejarse parece de mala educación
- Rara vez dice qué esperaba en su lugar
- Solo de quienes se molestan en hacerlo
Lo que te cuenta el agenteSegundos después
- Escrito mientras aún tiene cargado todo el contexto
- Sin juzgar si merece la pena hacerte perder el tiempo
- Indica qué esperaba, porque ese es el campo
- Identifica la llamada, el modelo y el entorno exactos
- De cada ejecución que se topa con el problema
Lo que más valoro es la falta de sesgo. Un agente no tiene ninguna relación contigo que proteger ni le preocupa parecer exigente. Ha leído tu descripción, se ha formado una expectativa y esa expectativa no se ha cumplido. Esa diferencia es todo el informe, y constituye la revisión más sincera de la documentación que recibirás nunca.
Adónde van los informes
Los míos se envían mediante POST a un webhook y llegan a un canal que leo. Esa es toda la configuración, y ya ha merecido la pena.
Puedes ir más allá. Las posibilidades se vuelven interesantes cuando los informes están estructurados:
- Guárdalos y agrúpalos por
related_action. Tres informes sobre la misma herramienta son una especificación, no una anécdota. - Recibe avisos sobre los que importan, filtrados según lo que te interese: una herramienta, un modelo o un entorno del agente.
- Pon un agente a gestionar la cola para eliminar duplicados, priorizar y preparar una propuesta de solución para tu repositorio. Los informes ya incluyen cómo reproducir el problema y el comportamiento esperado, que es casi todo lo que hace falta para resolverlo.
- Automatiza el proceso, si confías lo bastante en tus pruebas. Yo todavía no.
Nada de eso es imprescindible. El webhook por sí solo ya cambia lo que sabes sobre tu propio producto.
Dos reglas que no me saltaría
Nunca debe interrumpir la conversación que lo ha invocado. Si el webhook no funciona, la herramienta responde con un simple «no se ha podido entregar; no hay nada más que hacer», no con un error. Si un agente recibe una excepción de una herramienta de comentarios, empezará a tratar el fallo como parte de la tarea que estaba realizando. La mía también tiene un tiempo de espera corto por el mismo motivo: si el webhook se queda colgado, el turno del agente queda abierto.
Indica qué no se debe enviar. Los agentes quieren ayudar, y si pides contexto, podrían enviarte claves de API, URL firmadas y contenido de archivos. Basta con mencionarlo en la descripción para evitar almacenar cosas que nunca quisiste recibir.
Pruébalo con tu propio MCP
Si ya tienes un servidor MCP en producción, esto es una herramienta, un webhook y una descripción que reescribirás dos veces. El primer informe que recibas te contará algo de tu producto que no sabías, y será sobre una herramienta que creías que funcionaba bien.
Cuando empezaron a llegar esos informes de producción, monté una segunda parte para repetir el mismo ciclo antes del lanzamiento: poner en marcha agentes nuevos, sin contexto, en cada superficie, por medio céntimo cada ejecución. Documenté todo el proceso y publiqué el arnés como código abierto en Cómo publicar MCP con una puntuación de 10/10.
Los agentes ya son tus usuarios. Dales un sitio donde puedan quejarse.