AI Observabilidad del agente para cambios en la herramienta de MCP: prueba de convergencia de descubrimiento

Un agente AI que utiliza herramientas MCP no es saludable simplemente porque su proceso está vivo, su conexión con el servidor está abierta o ha recibido una notificación de cambio de lista de herramientas. La verificación práctica es más estricta: después de un cambio relevante, ¿completó el cliente un nuevo recorrido tools/list , siguió la paginación hasta el final y reemplazó su registro con las definiciones exactas de herramientas que descubrió? Trata eso como una prueba de convergencia. Registra la versión negociada del protocolo MCP y la capacidad de tools.listChanged , el último tiempo de notifications/tools/list changed , los tiempos de inicio y finalización del descubrimiento, cada cursor y los registros canónicos de los registros descubiertos e instalados. Regreso converged , stale , incomplete , o unverifiable . No conviertas la falta de evidencia en un resultado verde. Definir la convergencia en el límite del protocolo El Especificación del ciclo de vida del MCP requiere inicialización antes del funcionamiento normal. El cliente y el servidor negocian una versión del protocolo y las capacidades, y ambas partes deben respetar esa negociación. Una inicialización exitosa demuestra que una sesión comenzó bajo un contrato acordado. No demuestra que un cambio de herramienta posterior haya llegado al cliente. El Especificación de las herramientas de MCP suministra las siguientes piezas: un servidor que admita herramientas declara la capacidad tools ; listChanged indicará si emitirá notificaciones de cambio de lista de herramientas; los clientes descubren las definiciones a través de tools/list ; el descubrimiento puede ser paginado a través de nextCursor ; una definición de herramienta incluye más que su nombre, en particular inputSchema y outputSchema opcional, anotaciones y metadatos de ejecución. Esto crea tres eventos separados que el seguimiento no debe colapsar: 1. Cambio de señal: el cliente recibe notifications/tools/list changed . 2. Descubrimiento: inicia un nuevo cruce tools/list y alcanza una respuesta cuyo nextCursor está ausente o nulo. 3. Registry install: las definiciones utilizadas por el cliente coinciden con la instantánea de descubrimiento completada. La notificación es un indicio de actualización, no un recibo de actualización completa. Una primera página es actividad, no un registro completo. Los nombres coincidentes no son contratos coincidentes cuando se cambia un argumento requerido, esquema de salida o propiedad de ejecución. Mantenga las pruebas pequeñas pero decisivas Un historial de salud útil no necesita instrucciones, argumentos de herramientas, credenciales o resultados de herramientas. Necesita suficientes metadatos seguros para responder si el cliente y el servidor todavía están de acuerdo: El campo Lo que establece Lo que no establece protocolVersion La versión del MCP negociada para la sesión Que una versión posterior del servidor se mantuvo compatible tools.listChanged Si se negociaron las notificaciones de cambio Que cualquier notificación haya sido entregada o manejada notificationAt Un refresco se hizo debido Ese descubrimiento comenzó discoveryStartedAt y discoveryCompletedAt Una actualización limitada corrió después de la señal Que todas las páginas fueron recogidas cadena de cursores La página terminó sin hueco . Que el cliente instaló el resultado Digest de registro descubierto Identidad del conjunto completo de definiciones Que una llamada de herramienta tendrá éxito Digestión del registro de clientes Identidad de lo que el cliente expone actualmente al agente Que el agente elegirá correctamente Construye el digesto a partir de una proyección estable: name , title , description , inputSchema , outputSchema , annotations y execution . Ordenar las herramientas por nombre y canonizar JSON anidado antes de hashing. Los iconos decorativos se pueden excluir si no afectan a la selección o ejecución, pero la proyección misma debe ser versionada. RFC 8785 explica por qué el hashing repetible requiere una serialización invariante de JSON y una clasificación de propiedades recursivas. El ordenador recurrente compacto utilizado en este experimento es adecuado para los valores ordinarios de JSON de la fijación; no se presenta como una implementación completa de JCS. El código de producción debe utilizar una biblioteca de canonización revisada, especialmente cuando importan los casos de bordes numéricos o las firmas. No almacenar secretos crudos en la instantánea del registro. Los esquemas de herramientas deben describir las formas de los argumentos, no los valores de credenciales. Si una descripción contiene datos de inquilinos o rutas internas, redigela antes de recogerla y registre la versión de proyección que produjo la digestión. Reproducir una auditoría de registro de seis casos El dispositivo retenido utiliza seis observaciones sintéticas: una línea de base completa de dos páginas; una eliminación de la herramienta seguida de una actualización completa; una notificación de cambio seguida de ningún nuevo descubrimiento; la primera página con un nextCursor restante; el mismo nombre de la herramienta con un esquema de entrada requerida modificado; un servidor que no publicitara listChanged , sin pruebas de actualización limitadas. La orden de decisión principal es importante: Ejecutar la fijación con Node.js: La reproducción exacta regresó: Los contraejemplos son más útiles que los dos casos verdes. notification without refresh ha descubierto identico y el cliente se digiere, sin embargo su descubrimiento completado antes de la señal de cambio. Una coincidencia digestiva con una vieja instantánea todavía está obsoleta. unfinished pagination también tiene digestos correspondientes para la página observada, pero nextCursor permanece. Una coincidencia plausible de la primera página es evidencia incompleta. El caso del mismo nombre cambia read ticket de requerir sólo ticketId a requerir tanto projectId como ticketId . Un inventario solo de nombres declararía el registro sin cambios. La definición canónica de digestión cambia de c42521a2412558ca a c3837b93f14b688f , por lo que la antigua definición del cliente se clasifica como obsoleta. Convierte el veredicto en una decisión de operación. Utilice converged de forma estrecha. Significa que el registro de clientes observado coincide con un descubrimiento completamente cruzado completado después de la señal de cambio pertinente. No demuestra la accesibilidad del transporte para la próxima llamada, la autorización válida, el comportamiento correcto de la herramienta, un efecto externo exitoso o el resultado de la tarea prevista. Manejar los otros estados sin automatización agresiva: El veredicto Pruebas Seguimiento seguro . stale La actualización es más antigua que la señal, o los registros difieren Dejar de seleccionar la definición afectada; solicitar una actualización limitada; inspeccionar antes de volver a intentar el trabajo consecuente incomplete Se ha iniciado el descubrimiento pero faltan pruebas de cruce o finalización del cursor. Resume desde el cursor esperado si el cliente lo admite, de lo contrario reinicie el descubrimiento una vez unverifiable No existen pruebas de descubrimiento limitadas Informar la señal como no disponible; reconectar o programar una actualización controlada de acuerdo con la política de tiempo de ejecución converged Descubrimiento completo después del cambio y coincidencia exacta de la digestión Continuar, manteniendo controles separados de llamada, efecto y resultado Si el servidor no publicitó listChanged , se espera silencio y no puede establecer frescura. Definir una alternativa limitada: actualizar en la reconexión, antes de una ejecución de alto impacto, o en un intervalo medido que se ajuste a los límites de costo y velocidad del servidor. Registrar esa política para que no se confunda ninguna notificación con ningún cambio. También separar la salud del registro de la salud de la tarea. Una herramienta puede estar presente y describirse correctamente mientras su credencial haya expirado. Puede devolver isError: false mientras que el boleto prometido, archivo o despliegue está ausente. Después de cualquier recuperación aprobada, verifique el efecto externo o el resultado de la tarea en lugar de declarar el éxito porque se ha completado el descubrimiento o un comando. Preservación de los límites del producto y de la autoridad Esta verificación pertenece a la observabilidad del agente AI porque la disponibilidad de herramientas y la deriva de permisos pueden bloquear el progreso útil mientras el agente permanece activo. Es una señal de salud, no una autorización para reiniciar un tiempo de ejecución, rotar credenciales, invocar herramientas o repetir el gasto. La intervención consecuente debe permanecer limitada, visible y sujeta a la aprobación humana. La dirección prevista de Sidewisp es una capa de salud alrededor de los tiempos de funcionamiento de los agentes existentes: mostrar evidencia, frescura, severidad, incertidumbre y la siguiente acción más segura. El registro de convergencia de MCP en este artículo es un patrón operativo y un experimento, no una afirmación de que Sidewisp lo recoge actualmente. Sidewisp se encuentra actualmente en versión preliminar privada. El sitio público y el sistema de artículos están en vivo. La recopilación de agentes de producción salud, adaptadores de tiempo de ejecución de MCP, recuperación automática, gestión cron y análisis de costos de tokens generalmente no se envían. Únete a la vista previa privada si quieres ayudar a dar forma a los contratos de evidencia como la negociación de protocolos, la convergencia del registro, la disponibilidad de herramientas y los resultados verificados manteniendo la autoridad humana explícita.