Observabilité du PCM: établir un contrat de santé à cinq couches

L'observabilité du MCP devrait répondre à une question plus difficile que a t elle rendu la demande? Pour chaque session du protocole de contexte modèle, préserver une chaîne de preuves corrélative de l'autorisation et de l'initialisation à travers la découverte des outils, l'invocation, l'effet externe et les résultats attendus de l'utilisateur. Une réponse tools/call verte n'est qu'une seule liaison de cette chaîne. Le défaut raisonnable est un contrat de santé à cinq couches: 1. Session: Le client et le serveur ont ils négocié une version de protocole prise en charge et les capacités utilisées par cette exécution ? 2. Catalogue: Le client a t il lu la liste complète des outils actuels et réagi à un signal ultérieur de changement de liste? 3. Request: Pouvez vous rejoindre la demande JSON RPC, les notifications de progrès, l'annulation, la réponse et la date limite? 4. EEffect: Si l'outil modifie un système externe, y a t il des preuves de destination pour ce qui s'est réellement passé? 5. Ooutcome: a t il passé son vérificateur l'artefact, changement d'état, ou la décision que l'agent était censé produire? Ce contrat sépare délibérément l'activité du protocole du progrès utile. Il donne également à l'opérateur un état de béton pour l'itinéraire: needs auth , incompatible session , stale catalog , working , protocol error , tool failed , effect unknown , false success ou healthy . Commencez par une chaîne de preuves, pas un numéro de tableau de bord. Les nouveaux résultats américains pour l'observabilité de l'mcp mettent l'accent sur les sessions, les connexions, l'analyse des outils, la latence des transports, le débit et les erreurs. Elles sont utiles. Le Documentation de l'observabilité du MCP actuel de Grafana répertorie l'établissement de la session, la stabilité de la connexion, la conformité au protocole, les performances des outils et la fiabilité du transport. L'écart n'est pas que ces signaux sont erronés. L'écart est qu'aucun d'eux, seul, ne prouve que le travail prévu par l'agent a atteint sa destination. Les dossiers médicaux peuvent rester compacts: Les hashs sont des identifiants, pas une autorisation pour télécharger des schémas d'outils, des arguments, des invites, des jetons ou du contenu retourné. Gardez des valeurs sensibles sur l'hôte. Enregistrer les plus petits champs nécessaires pour corréler l'état et prouver la décision. Le contrat devrait également disposer d'une règle de priorité. L'échec de l'autorisation précède la santé de la session; une session incompatible précède la fraîcheur du catalogue; un catalogue non résolu précède l'interprétation de la demande; un délai de transport à une limite d'effet secondaire devient effect unknown , pas une reprise automatique; et un appel réussi avec un produit manquant devient false success , pas sain. Faire l'état du protocole observable avant de mesurer la latence de l'outil Le MCP spécification du cycle de vie fait de l'initialisation la première interaction client serveur. Les deux parties se mettent d'accord sur une version du protocole, échanger des capacités, puis entrer en fonctionnement normal. Le même document stipule que la communication ultérieure doit respecter la version négociée et les capacités. Cela donne à l'observabilité un premier point de contrôle propre: stocker la version demandée, la version acceptée, le jeu de capacités et le moment où le client a envoyé notifications/initialized . N'écrasez pas chaque défaillance avant ce point dans server vers le bas. Pour les transports HTTP, l'autorisation est une passerelle séparée. Le Spécification de l'autorisation de MCP actuel définit la découverte de ressources protégées et exige que les clients gèrent un défi 401 Unauthorized . Un serveur peut être accessible et correcte alors que le client manque d'un jeton, a la mauvaise portée ou ne peut pas découvrir le serveur d'autorisation. Envoyez le comme needs auth ; ne le traitez pas comme une panne de transport. La découverte d'outils a besoin de sa propre preuve d'exhaustivité. Le spécification des outils dit que tools/list est paginé et que les serveurs déclarant listChanged peuvent émettre notifications/tools/list changed . Par conséquent, nous avons reçu une page n'est pas un nouveau catalogue. Le dossier: la capacité d'initialisation qui annonce les outils; chaque curseur de pagination jusqu'à ce qu'aucun nextCursor ne reste; un hash canonique de noms et de schémas d'entrée/sortie; la dernière période de rafraîchissement réussie; toute notification tools/list changed et la mise à jour qui en a suivi. C'est plus étroit que d'enregistrer chaque schéma. Un client peut calculer le hash localement et ne conserver que le hash, le nombre d'outils, le nombre de pages et la mise à jour des preuves. Si une notification de changement arrive et que la mise à jour échoue, classez la session stale catalog . Le serveur peut toujours répondre aux pings, mais le modèle pourrait choisir entre un contrat d'outil obsolète. Des appels longs introduisent un autre piège. Le MCP notifications d'avancement utilise un jeton fourni à la demande qui doit être unique parmi les demandes actives; les valeurs de progression doivent augmenter et les notifications doivent cesser après la finalisation. Cette preuve peut justifier working tant que l'appel est dans son délai maximum. Elle ne prouve pas que le travail est utile et ne doit jamais prolonger le délai à jamais. Un message répété sans valeur croissante, un jeton attaché à la mauvaise demande ou des progrès après une réponse finale sont des preuves incohérentes. Utilisez deux horloges: une fenêtre d'inactivité, qui peut être réinitialisée sur une progression monotone valide; une date limite maximale absolue, qui ne peut pas être réinitialisée. Cette distinction empêche deux erreurs opposées: tuer un travail long légitime parce qu'il n'est pas encore revenu, et accepter un flux infini de notifications de progrès comme une santé. Un appel à l' outil réussi n' est pas le résultat MCP distingue les erreurs de protocole des erreurs d'exécution des outils. Selon la spécification des outils, les requêtes malformées et les outils inconnus utilisent des erreurs JSON RPC, tandis que les défaillances d'entreprise ou d'entrée peuvent renvoyer un résultat de l'outil avec isError: true . Gardez ces états séparés car la prochaine action est différente: fixer le contrat client pour protocol error ; ajuster les entrées, les autorisations ou la dépendance en aval pour tool failed . Le cas le plus dangereux est l'absence de réponse après un effet secondaire. Supposons que publish report fois hors. Une nouvelle tentative immédiate peut créer un rapport dupliqué parce que l'incertitude du transport ne dit rien sur la destination. Marquer l'appel effect unknown , reconcilier en utilisant une clé d'opération stable ou une requête de destination, et ne réessayer que lorsque les preuves prouvent que la première tentative n'a pas été engagée. Même un résultat normal ne suffit pas. Le serveur peut retourner isError: false alors que le fichier promis est absent, que l'enregistrement à distance est toujours un projet ou que l'URL est privée. Ajoutez un vérificateur de résultat choisi avant l'appel: hash de fichier, ligne de base de données plus version, statut HTTP public, résultat de test ou autre reçu déterministe. Utilisez un juge LLM uniquement lorsque le résultat ne peut pas être vérifié directement, et étiquettez les preuves plus faibles. Cela crée trois états terminalisés distincts: Résultat du protocole Effect de destination Résultat attendu L'état de santé temps de réparation inconnu inconnu effect unknown réussite vérifié échoué ou manquant false success réussite vérifié vérifié healthy La rangée du milieu compte le plus. Il empêche un échange de protocoles réussi de devenir une fausse affirmation selon laquelle l'agent a terminé la tâche de l'utilisateur. Refaire le contrat contre les cas inconvenients L'artefact qui l'accompagne est un dispositif illustratif de neuf cas et un classificateur déterministe. Il ne contient pas de télémétrie de production. Faites le avec: Le fichier couvre une exportation saine et huit limites inconvenientes: un défi d'autorisation, une version de protocole non prise en charge, un changement de liste d'outils non reconcilié, un appel de longue durée avec des progrès valides, un appel malformé, une erreur d'exécution de l'outil, un délai après un éventuel effet secondaire et un succès avec un produit manquant. Le classificateur a renvoyé un cas dans chaque état attendu: C'est la partie falsifiable de la méthode: changer les preuves et l'état doit changer de manière prévisible. Si le tools/list changed est suivi d'une mise à jour complète, le dossier de catalogue périmé doit être avancé. Si l'appel à temps partiel obtient un reçu de destination mais que son vérificateur livrable échoue, il devrait passer de effect unknown à false success . Il n'atteint healthy que lorsque la session, le catalogue, la demande, l'effet et les preuves des résultats sont tous d'accord. L'artefact ne valide pas si la sémantique commerciale d'un outil est correcte. Il ne détecte pas d'effet secondaire non documenté, ne prouve pas que l'émetteur de OAuth est digne de confiance ou ne décide pas de la durée de votre délai. Ce sont des examens spécifiques au déploiement. Son travail est plus petit: empêcher que les preuves manquantes ne soient silencieusement rendues vertes. Alerte sur l'état qui a besoin d'action N'envoyez pas tous les états malsains dans le même canal. needs auth est attribué au titulaire de la carte d'identité ou de l'autorisation avec la ressource contestée et la portée requise, jamais la valeur du jeton. incompatible session va au propriétaire de l'intégration avec la version client, la version serveur et les capacités négociées. stale catalog déclenche une tentative de redécouverte limitée; l'échec répété devient un incident d'intégration. working reste silencieux tant que les progrès sont valides et que le délai absolu reste. protocol error va à l'implémentateur client avec la méthode, l'identifiant de demande et la classe d'erreur désinfectée. tool failed ne suit la politique de réessayer de l'outil que lorsque la défaillance est connue comme réversible. Le effect unknown bloque automatiquement la nouvelle tentative à la limite de l'effet secondaire et démarre la réconciliation. false success ouvre un incident de résultat même si le MCP lui même est terminé. Ce routage maintient l'attente distincte de l'accès. Une demande d'autorisation attribuée à une personne peut être une attente légitime; un jeton de progrès avançant dans une demande limitée peut être un travail; un catalogue inchangé après un signal de changement de liste n'est ni. Commencez par un seul outil de grande valeur et un véritable vérificateur de résultats. Capturez la chaîne pendant une semaine, inspectez chaque état inconnu, puis ajoutez la couverture. Un tableau de bord parfait à l'échelle de la flotte construit sur des événements non corrélés est moins utile qu'un appel d'outil dont la session, l'effet et le résultat peuvent être expliqués de bout en bout. Lorsque ce contrat prend fin L'observabilité du MCP peut établir des protocoles et des preuves opérationnelles, mais elle ne peut pas déduire toutes les intentions de l'utilisateur à partir du fil. Un schéma de sortie valide prouve la forme, pas la vérité. Un reçu de destination prouve un effet, pas que l'effet a été sage. Un signal de progression monotone prouve le mouvement rapporté par le serveur, pas un progrès utile vers l'objectif de l'utilisateur. Ces limites nécessitent des contrôles d'application et parfois un jugement humain. Sidewisp est actuellement en préversion privée. Ses adaptateurs de surveillance de la production et ses systèmes de récupération ne sont généralement pas expédiés. Le contrat visé au présent article est une méthode de fonctionnement et un artefact local inspectable, et non une affirmation selon laquelle Sidewisp collecte déjà des séances MCP ou les répare. L'orientation du produit envisagée est de rendre plus facile de voir les preuves de santé, l'incertitude et les limites d'approbation en même temps que les délais d'exécution existants. Si vous concevez une intégration MCP maintenant, gardez le registre à cinq couches local, modifiez le contenu et refusez d'appeler une course saine jusqu'à ce que le résultat attendu ait sa propre réception. Cette règle unique transforme la télémétrie du protocole en une décision opérationnelle au lieu d'un autre graphique vert.