La mayoría de los operadores que conectan el agente al MCP de Cabgo terminan la configuración inicial y no vuelven a revisar si las llamadas que hace el agente son correctas. No porque no les importe, sino porque no tienen un ritual de revisión establecido. El agente responde preguntas, genera reportes, ejecuta acciones — y mientras funciona, el operador asume que funciona bien. El problema es que un agente que «funciona» y un agente que funciona correctamente son dos cosas distintas: el primero responde, el segundo responde con las herramientas correctas, al tenant correcto, sin retries innecesarios y sin patrones de llamada que indiquen que está aprendiendo sobre la marcha convenciones que debería tener precargadas desde el skill.
El servidor MCP de Cabgo registra cada llamada del agente en el historial accesible a través de `cabgo_my_mcp_usage` — herramienta activada, timestamp, tenantId resuelto, estado del resultado y cantidad de retries. Ese historial es la diferencia entre asumir que el agente opera correctamente y poder verificarlo. Este artículo documenta qué revisar en ese historial cada semana, qué patrones indican problemas antes de que el operador los note en el output diario, y qué acciones tomar cuando un patrón se desvía de lo esperado. La revisión completa no toma más de 10 minutos — pero convierte al agente de una herramienta que se usa con fe en una que se usa con evidencia.
Qué registra el servidor MCP en cada llamada del agente
El historial de uso del MCP no es un log de errores — es un registro de cada interacción, exitosa o no. Cada entrada tiene cinco campos que importan para la auditoría semanal: la herramienta llamada (`tool_name`), el timestamp exacto, el tenantId que el agente resolvió para esa llamada (puede ser el default o uno especificado explícitamente en el prompt), el estado del resultado (`success`, `tier4_confirmation`, `rejected`, `timeout`) y el número de retries antes de que la llamada se resolviera. La mayoría de los operadores nunca ha visto este historial porque el agente no lo muestra por defecto — hay que pedirlo explícitamente con un prompt dirigido a `cabgo_my_mcp_usage`. Lo que aparece en esas entradas en 10 minutos revela más sobre cómo opera el agente que semanas de conversación normal.
El campo más informativo para detectar problemas es `retry_count`. Un valor de cero significa que el agente llamó la herramienta una vez y obtuvo el resultado esperado en el primer intento — el flujo ideal. Un valor de uno puede ser normal en conexiones con latencia variable. Dos o más retries en la misma llamada, en particular cuando se trata de herramientas destructivas como actualizaciones de configuración o cambios de precio, indica casi siempre que el agente recibió una tarjeta de confirmación Tier-4 y la interpretó como un error transitorio reintentable — comportamiento que sucede cuando el skill no está cargado o no se está activando.
Cinco patrones de alerta que aparecen antes de que el operador note el problema
Los problemas de configuración del agente no aparecen de golpe — aparecen como patrones en el historial de llamadas antes de que el operador note que algo está mal en el output diario. Hay cinco patrones que vale la pena buscar en cada revisión semanal:
- Llamadas frecuentes a `cabgo_about` antes de otras herramientas: el agente está haciendo descubrimiento del catálogo en cada sesión porque no tiene el contexto precargado del skill. En operaciones donde el skill está correctamente instalado, `cabgo_about` debería aparecer solo en la primera sesión de un operador nuevo, no semana tras semana.
- tenantId resuelto como 'default' en más del 50% de las llamadas cuando la operación tiene varias apps activas: en un flujo multi-tenant correcto, las llamadas deben distribuirse entre tenants según el trabajo del operador. Una concentración alta en el default puede indicar que los prompts no están especificando el tenant secundario cuando la tarea lo requiere.
- Estado `tier4_confirmation` seguido de `timeout` sin `success`: el agente recibió la tarjeta de confirmación de una herramienta destructiva y no completó el flujo en el TTL de cinco minutos. Indica que el operador cerró la conversación antes de confirmar, o que el agente reintentó la llamada en lugar de presentar la tarjeta para aprobación.
- `cabgo_list_builds` apareciendo en contextos de estado operativo diario: esta herramienta devuelve el historial de deploys, no el estado de la operación en tiempo real. Su presencia en esos contextos indica que el agente confundió dos herramientas de nombres parecidos pero propósitos distintos — confusión que el skill resuelve con su tabla de selección.
- Llamadas en horarios que el operador no usa el agente: si el historial muestra actividad a las 2am o en días que el operador no abrió su cliente, puede indicar una integración externa usando el mismo token, o un script automatizado no documentado. Merece investigación antes de convertirse en un problema de costos o de seguridad.
Cómo solicitar el historial con un prompt que entrega output accionable
El historial de `cabgo_my_mcp_usage` no es una pantalla del dashboard — es una herramienta del servidor MCP que el agente llama cuando el operador se lo pide. El output por defecto incluye las últimas 50 llamadas, lo que en una operación activa cubre entre 3 y 5 días. Para una revisión semanal completa, el prompt debe especificar el período y el formato esperado; de lo contrario, el agente produce una narración libre difícil de comparar semana a semana. El prompt de auditoría debería guardarse en la biblioteca de prompts del operador junto con los cinco prompts de trabajo diario — es el sexto que completa el ciclo operativo.
Qué confirma un historial limpio y qué delata uno con ruido
Un historial semanal limpio tiene tres características: la gran mayoría de las llamadas tienen estado `success` en el primer intento, las herramientas llamadas corresponden al tipo de tarea que el operador realiza habitualmente (reportes con herramientas de lectura, acciones con herramientas de escritura), y los tenantIds reflejan el patrón de trabajo real. Cuando los tres indicadores están alineados, el agente opera dentro de las convenciones del skill — no hay ajustes urgentes. Un historial limpio no requiere acción: solo confirma que la configuración actual sostiene el trabajo de la semana sin desgaste.
Un historial con ruido — retries elevados, herramientas de descubrimiento antes de cada acción, estado `rejected` en llamadas que el operador cree que ejecutó con éxito — delata uno de dos problemas: configuración del agente o deriva del prompt. La configuración involucra el skill y el token; la deriva del prompt sucede cuando el operador empieza a modificar sus plantillas guardadas sin preservar la especificidad que las hace funcionar. El historial distingue los dos casos porque los problemas de configuración producen patrones sistemáticos — el mismo error en llamadas distintas — mientras que la deriva del prompt produce errores específicos, que aparecen solo en ciertas herramientas o ciertos tenants. Saber cuál es cuál antes de actuar evita arreglar lo que no está roto.
La revisión semanal: cinco preguntas que cubren la operación en diez minutos
Una revisión productiva no requiere leer cada entrada del historial — requiere hacer cinco preguntas concretas sobre el output de `cabgo_my_mcp_usage`. Si las respuestas están dentro del rango esperado, la operación del agente está sana. Si una se desvía, señala exactamente dónde mirar sin necesidad de una auditoría exhaustiva:
- ¿El promedio de retries por llamada está por debajo de 0.5 esta semana? Un promedio mayor indica que el agente está reintentando en lugar de completar flujos en el primer intento — la causa más común es la tarjeta Tier-4 no reconocida por falta de skill.
- ¿Las llamadas a herramientas destructivas tienen estado `success` o `tier4_confirmation` — no `rejected` o `timeout`? Un `timeout` o `rejected` en estas herramientas significa que el flujo de confirmación no se completó dentro del TTL de cinco minutos.
- ¿La distribución de tenantId en las llamadas refleja cómo el operador usa sus apps? Si tiene taxi y delivery activos y el 90% o más de las llamadas van siempre al mismo tenant, los prompts secundarios probablemente no están especificando el tenant correcto cuando la tarea lo requiere.
- ¿Hay alguna herramienta con un volumen de llamadas muy superior al esperado para la semana? Un pico en una herramienta específica puede indicar un bucle del agente o una automatización externa no documentada con acceso al token.
- ¿El volumen total de llamadas de la semana es consistente con la frecuencia real de uso del operador? Una discrepancia grande — más del doble del volumen típico o actividad en horarios inusuales — merece investigación antes de que se convierta en un problema de costos.
Problemas de configuración vs bugs de plataforma: cómo distinguirlos y qué hacer con cada uno
Hay una distinción importante entre un patrón que indica un problema de configuración — que el operador puede resolver solo — y uno que indica comportamiento inesperado del servidor MCP, que requiere soporte técnico. La regla práctica: si el historial muestra llamadas correctas por parte del agente seguidas de respuestas inesperadas o errores no documentados del servidor, es un problema de plataforma. Si el historial muestra llamadas incorrectas — herramienta equivocada, tenantId faltante, retries ante Tier-4 — es un problema de configuración del agente. Los problemas de configuración son más frecuentes y tienen solución directa: skill no instalado (instalarlo), skill instalado pero no activándose (verificar que el directorio sea el correcto y el archivo se llame exactamente SKILL.md), prompts que no especifican tenantId en operaciones multi-tenant (agregar el campo), confusión sistemática entre herramientas de lectura y escritura (revisar la tabla de selección del skill).
Los bugs de plataforma — respuestas con formato inesperado, herramientas del catálogo que devuelven errores no documentados, tokens que expiran antes del TTL declarado, tenantIds válidos que el servidor no reconoce — se reportan como issues en el repositorio del skill o directamente al equipo de Cabgo. El extracto relevante del historial de `cabgo_my_mcp_usage` es la evidencia más útil para ese reporte: muestra exactamente qué llamó el agente, cuándo, con qué tenantId y qué respuesta recibió. Un reporte sin ese extracto obliga al equipo a reproducir el problema desde cero; uno con el extracto permite identificar el origen en minutos.
La primera semana que revisé el historial, vi que el agente había reintentado la tarjeta de confirmación tres veces antes de que yo cerrara la conversación. Eso me dijo que el skill no estaba cargado correctamente — estaba tratando el Tier-4 como un error del servidor. Diez minutos de revisión me dieron más claridad que dos semanas de prompts de prueba y error.
El agente conectado al MCP de Cabgo no es invisible para quien sabe dónde mirar. El historial de `cabgo_my_mcp_usage` registra cada decisión de herramienta, cada tenantId resuelto, cada retry, cada confirmación pendiente. Eso convierte la revisión semanal de 10 minutos en el único control de calidad que corre a un nivel más profundo que los prompts: no solo verifica que el agente respondió, sino que respondió de la manera correcta, con las herramientas correctas, sin patrones que indiquen que se están perdiendo convenciones clave en la ejecución diaria.
El arco completo de una operación bien configurada con agentes tiene tres capas: conectar el MCP con el skill instalado, definir los prompts de trabajo diario, y auditar el historial cada semana para confirmar que las tres capas siguen alineadas. La mayoría de los operadores tiene las primeras dos. La revisión semanal es la tercera capa — la que convierte al agente de una herramienta que se usa con fe en una que se usa con evidencia. Diez minutos el lunes por la mañana es el costo de esa diferencia.
