AI Observabilité de l'agent pour les modifications de l'outil MCP: prouver la convergence de la découverte

Un agent AI qui utilise des outils MCP n'est pas en bonne santé simplement parce que son processus est en vie, que sa connexion au serveur est ouverte ou qu'il a reçu une notification de changement de liste d'outils. La vérification pratique est plus stricte: après un changement pertinent, le client a t il effectué un nouveau traversage tools/list , suivi la pagination jusqu'à la fin et remplacé son registre par les définitions exactes de l'outil qu'il a découvertes? Traitez ça comme un test de convergence. Enregistrer la version du protocole MCP négociée et la capacité de tools.listChanged , le dernier temps de notifications/tools/list changed , les temps de démarrage et de finalisation de la découverte, chaque curseur et les digestions canoniques des registres découverts et installés. Retour converged , stale , incomplete ou unverifiable Ne transforme pas les preuves manquantes en un résultat vert. Définir la convergence à la limite du protocole Le Spécification du cycle de vie du MCP nécessite une initialisation avant le fonctionnement normal. Le client et le serveur négocient une version du protocole et des capacités, et les deux parties doivent respecter cette négociation. Une initialisation réussie prouve qu'une session a commencé sous un contrat convenu. Il ne prouve pas qu'un changement d'outil ultérieur ait atteint le client. Le Spécification des outils du MCP fournit les pièces suivantes: un serveur qui prend en charge les outils déclare la capacité tools ; listChanged indique si elle émettra des notifications de changement de liste d'outils; les clients découvrent des définitions par l'intermédiaire de tools/list ; la découverte peut être paginée à travers nextCursor ; une définition d'outil comprend plus que son nom, notamment inputSchema et outputSchema facultatif, des annotations et des métadonnées d'exécution. Cela crée trois événements distincts que la surveillance ne doit pas annuler: 1. Change de signal: le client reçoit notifications/tools/list changed . 2. Discovery: il démarre une nouvelle traversée tools/list et atteint une réponse dont nextCursor est absent ou nul. 3. Registry install: Les définitions utilisées par le client correspondent à l'instantané de découverte terminée. La notification est un indice de rafraîchissement, pas un reçu de rafraîchissement complet. Une première page est une activité, pas un registre complet. Les noms correspondants ne sont pas des contrats correspondants lorsqu'un argument requis, un schéma de sortie ou une propriété d'exécution sont modifiés. Gardez les preuves petites mais décisives Un dossier médical utile n'a pas besoin d'informations, d'arguments d'outils, de certificats ou de résultats d'outils. Il faut suffisamment de métadonnées sécurisées pour répondre si le client et le serveur sont toujours d'accord: champs Ce qu'elle établit Ce qu'elle n'établit pas protocolVersion La version du PCM négociée pour la session Qu' une version ultérieure du serveur est restée compatible tools.listChanged Si des notifications de changement ont été négociées Que toute notification a été délivrée ou traitée notificationAt Un rafraîchissement est venu Cette découverte a commencé discoveryStartedAt et discoveryCompletedAt Un rafraîchissement limité a suivi le signal Que chaque page a été récupérée chaîne de curseur La page s'est terminée sans écart. Que le client a installé le résultat Digest du registre découvert Identification de l'ensemble de définitions complet Que l'appel à l' outil réussira Digest du registre des clients Identification de ce que le client expose actuellement à l'agent Que l' agent choisira correctement Construire le digeste à partir d'une projection stable: name , title , description , inputSchema , outputSchema , annotations et execution . Sélectionner les outils par nom et canoniser le JSON niché avant le hachage. Les icônes décoratives peuvent être exclues si elles n'affectent pas la sélection ou l'exécution, mais la projection elle même doit être versionnée. RFC 8785 explique pourquoi le hachage répétable nécessite une sérialisation invariante JSON et un tri des propriétés récursives. Le sélecteur récursif compact utilisé dans cette expérience est adéquat pour les valeurs ordinaires JSON du dispositif; il n'est pas présenté comme une mise en œuvre complète de JCS. Le code de production doit utiliser une bibliothèque de canonisation révisée, en particulier lorsque les cas de bord numérique ou les signatures sont importants. Ne conservez pas les secrets bruts dans l'instantané du registre. Les schémas d'outils devraient décrire les formes d'arguments et non les valeurs de crédibilité. Si une description contient des données des locataires ou des itinéraires internes, éditez la avant de la collecter et enregistrez la version de projection qui a produit la digestion. Reproduction d'une vérification du registre en six cas Le dispositif conservé utilise six observations synthétiques: une ligne de base complète de deux pages; un retrait de l'outil suivi d'un rafraîchissement complet; une notification de changement suivie d'aucune nouvelle découverte; la première page avec un nextCursor restant; le même nom de l'outil avec un schéma d'entrée requise modifié; un serveur qui n'a pas annoncé listChanged , sans preuve de mise à jour limitée. L'ordre décisionnel de base est important: Exécutez le fichier avec Node.js: La répétition exacte est revenue: Les contre exemples sont plus utiles que les deux cas verts. notification without refresh a identique découverte et digeste le client, mais sa découverte a été achevée avant le signal de changement. Une correspondance digestive avec un vieux instantané est encore obsolète. unfinished pagination a également des digests correspondants pour la page observée, mais nextCursor reste. Une correspondance plausible est une preuve incomplète. Le cas du même nom modifie read ticket d'exiger uniquement ticketId à exiger à la fois projectId et ticketId . Un inventaire nommé ne changerait pas le registre. La définition canonique de digestion change de c42521a2412558ca à c3837b93f14b688f , de sorte que l'ancienne définition du client est classée comme obsolète. Transformer le verdict en décision opérationnelle Utilisez le converged de manière étroite. Cela signifie que le registre de clients observé correspond à une découverte entièrement traversée réalisée après le signal de changement pertinent. Il ne prouve pas la disponibilité du transport pour l'appel suivant, une autorisation valide, un comportement correct de l'outil, un effet externe réussi ou le résultat de la tâche prévue. Gérer les autres états sans automatisation agressive: Le verdict Les preuves La prochaine étape est sûre. stale La mise à jour est plus ancienne que le signal, ou les registres diffèrent Arrêter de sélectionner la définition affectée; demander une mise à jour limitée; inspecter avant de réessayer le travail consécutif incomplete La découverte a commencé mais les preuves de traversée ou d'achèvement du curseur sont manquantes. Résumez à partir du curseur attendu si le client le prend en charge, sinon redémarrez la découverte une fois unverifiable Aucune preuve de découverte limitée n' existe Indiquer que le signal n'est pas disponible; reconnecter ou planifier un rafraîchissement contrôlé selon la politique du temps d'exécution converged Découverte complète après changement et correspondance exacte de la digestion Continuer, tout en conservant des contrôles séparés d'appel, d'effet et de résultat Si le serveur n'a pas annoncé listChanged , le silence est attendu et ne peut pas établir la fraîcheur. Définir une alternative limitée: rafraîchir lors de la reconnexion, avant une course à fort impact ou à un intervalle mesuré qui correspond aux limites de coût et de taux du serveur. Enregistrer cette politique afin que no notification ne soit pas confondu avec no change. Il est également possible de séparer la santé du registre de la santé des tâches. Un outil peut être présent et correctement décrit tant que son accréditation est expirée. Il peut retourner isError: false alors que le billet, le fichier ou le déploiement promis est absent. Après une récupération approuvée, vérifiez l'effet externe ou le résultat de la tâche au lieu de déclarer le succès parce que la découverte ou une commande a été terminée. Préserver les limites du produit et de l'autorité Cette vérification appartient à l'observabilité de l'agent AI car la disponibilité des outils et la dérive des autorisations peuvent bloquer les progrès utiles pendant que l'agent reste actif. C'est un signal de santé, pas une autorisation pour redémarrer une course, faire tourner les informations, invoquer des outils ou répéter les dépenses. L'intervention qui en résulte devrait rester limitée, visible et soumise à l'approbation humaine. L'orientation prévue par Sidewisp est une couche de santé autour des délais d'exécution existants de l'agent: montrer la preuve, la fraîcheur, la gravité, l'incertitude et la prochaine action la plus sûre. L'enregistrement de convergence des MCP présenté dans cet article est un modèle d'exploitation et une expérience, et non une affirmation selon laquelle Sidewisp le recueille actuellement. Sidewisp est actuellement en préversion privée. Le site public et le système d'articles sont en direct. La collecte des agents de production et de la santé, les adaptateurs de temps d'exécution MCP, la récupération automatisée, la gestion du cron et l'analyse des coûts des jetons ne sont généralement pas expédiés. Rejoignez l'aperçu privé si vous voulez aider à façonner les contrats de preuve tels que la négociation de protocoles, la convergence du registre, la disponibilité des outils et les résultats vérifiés tout en gardant l'autorité humaine explicite.