Fallos silenciosos: cuando la herramienta del agente responde a medias

Una llamada a una herramienta que devuelve un código 200, un JSON bien formado y ningún mensaje de error puede estar fallando igualmente. Esa es la idea central de un trabajo publicado esta semana en arXiv que audita 15 herramientas científicas integradas en ToolUniverse, junto con la documentación de sus APIs y de las propias herramientas, en busca de un tipo de error que casi ningún benchmark mide.

Los autores lo llaman fallo silencioso: la invocación parece haber funcionado, pero parte de la información o de la funcionalidad que la herramienta ofrece a través de su API o de su wrapper falta o llega incompleta, y ni el agente ni el usuario reciben aviso alguno. El agente sigue razonando sobre datos parciales como si estuvieran completos.

Qué mide el estudio

La mayoría de evaluaciones de sistemas agénticos se fijan en si la tarea se completa. El artículo, titulado Silent Failures in Agent-Tool Interaction: An Audit of ToolUniverse, plantea otra pregunta: qué ocurre en la frontera entre el agente y la herramienta, en concreto en flujos de trabajo de biología, un terreno donde según los autores la investigación todavía es escasa.

Para responderla desarrollan un mecanismo de auditoría y organizan el análisis en torno a siete loci de fallo, es decir, siete puntos de la cadena donde puede originarse la pérdida de información. El resumen insiste en un matiz importante: ToolUniverse es el entorno experimental, no el objeto de estudio. El problema no es de ese proyecto en particular, sino de la capa que envuelve APIs de terceros para que un modelo pueda usarlas.

Cómo se reconoce un fallo silencioso

Sin entrar en los casos concretos del paper, el patrón resulta familiar para cualquiera que haya escrito un conector:

Una API pagina los resultados y el wrapper solo devuelve la primera página, sin indicar que hay más.
La documentación de la API ofrece filtros o campos que el wrapper no expone, de modo que el agente nunca sabe que existen.
Un error en el servicio de origen se convierte en una lista vacía, que el agente interpreta como ausencia de resultados.
Un campo largo se trunca para ahorrar tokens y la respuesta no lo señala.

En todos estos casos el agente recibe una respuesta sintácticamente correcta y nada en el flujo le invita a sospechar. En biología las consecuencias son directas: una búsqueda de variantes, interacciones o publicaciones que devuelve la mitad de los resultados produce conclusiones que parecen sólidas y no lo son.

Por qué importa fuera del laboratorio

Aunque el estudio se centra en herramientas científicas, la lección vale para cualquier servidor MCP que envuelva una API externa. MCP resuelve cómo se describe y se invoca una herramienta, pero la fidelidad de lo que devuelve depende de quien escribe el wrapper. La especificación ya incluye piezas útiles, como el indicador `isError` en los resultados de las herramientas o los esquemas de salida estructurada, aunque solo sirven si el servidor los usa con honestidad.

A partir de este diagnóstico, estas son las prácticas que recomendamos a quien construye conectores:

Comparar de forma periódica la salida del wrapper con la de la API original, no solo comprobar que responde.
Declarar de forma explícita cuándo una respuesta es parcial: total de resultados, cursor de paginación, campos omitidos.
Distinguir en la respuesta entre «no hay datos» y «no se han podido obtener».
Revisar la cobertura del wrapper frente a la documentación de la API cada vez que esta cambie.

En Claude Code, además, un hook `PostToolUse` permite inspeccionar la respuesta de una herramienta antes de que el agente continúe, un buen lugar para comprobaciones de completitud en flujos sensibles.

Para quién es útil

Interesa a los equipos de bioinformática e I+D que ya encadenan agentes con bases de datos públicas y a quienes desarrollan o mantienen servidores MCP. También a quien evalúa agentes solo por su tasa de éxito, que quizá es el grupo que más debería leerlo: una tarea marcada como completada con datos incompletos cuenta como éxito en casi cualquier benchmark.

Nos parece un trabajo valioso precisamente porque no habla de modelos, sino de fontanería. Buena parte de los errores que vemos en agentes en producción nacen en esa capa, y auditar los wrappers con el mismo rigor que los prompts sigue siendo una tarea pendiente en muchos proyectos.