AI Agente Osservabilità per le modifiche degli strumenti MCP: dimostra la convergenza della scoperta

Un agente AI che utilizza strumenti MCP non è sano semplicemente perché il suo processo è vivo, la sua connessione al server è aperta o ha ricevuto una notifica di modifica della lista degli strumenti. Il controllo pratico è più rigoroso: dopo una modifica pertinente, il cliente ha completato una nuova traversata tools/list , seguito la paginazione fino alla fine, e sostituito il suo registro con le esatte definizioni degli strumenti che ha scoperto? Tratta questo come un test di convergenza. Registrare la versione del protocollo MCP negoziata e la capacità di tools.listChanged , l'ultimo tempo di notifications/tools/list changed , i tempi di avvio e di completamento della scoperta, ogni cursore e le digestioni canoniche dei registri scoperti e installati. Ritorna converged , stale , incomplete o unverifiable . Non trasformare le prove mancanti in un risultato verde. Definire la convergenza al confine del protocollo Il Specifica del ciclo di vita del MCP richiede l'inizializzazione prima del normale funzionamento. Il client e il server negoziano una versione del protocollo e le sue funzionalità, e entrambe le parti devono rispettare tale negoziazione. Una inizializzazione riuscita dimostra che una sessione è iniziata in base a un contratto concordato. Ciò non dimostra che una successiva modifica degli strumenti abbia raggiunto il cliente. La Specifica degli strumenti MCP fornisce i seguenti pezzi: un server che supporta strumenti dichiara la capacità tools ; listChanged indica se emetterà notifiche di modifica dell'elenco degli strumenti; i clienti scoprono le definizioni tramite tools/list ; la scoperta può essere paginata tramite nextCursor ; una definizione di strumento include più di un nome, in particolare inputSchema e outputSchema opzionale, annotamenti e metadati di esecuzione. Ciò crea tre eventi separati che il monitoraggio non deve collassare: 1. Cambiamento di segnale: il cliente riceve notifications/tools/list changed . 2. Discovery: inizia una nuova traversata tools/list e raggiunge una risposta la cui nextCursor è assente o nulo. 3. Registry install: le definizioni utilizzate dal cliente corrispondono allo snapshot di scoperta completato. La notifica è un suggerimento per rinfrescare, non una ricevuta per il rinfresco completato. Una prima pagina è un'attività, non un registro completo. I nomi corrispondenti non sono contratti corrispondenti quando un argomento richiesto, uno schema di uscita o una proprietà di esecuzione sono cambiati. Tenere le prove piccole ma decisive Un utile registro sanitario non ha bisogno di richieste, argomentazioni di strumenti, credenziali o risultati degli strumenti. Ha bisogno di abbastanza metadati sicuri per rispondere se il client e il server sono ancora d'accordo: Campo Ciò che essa stabilisce Ciò che non stabilisce protocolVersion La versione del MCP negoziata per la sessione Che una versione successiva del server è rimasta compatibile tools.listChanged Se le notifiche di modifica sono state negoziate Che qualsiasi notifica sia stata consegnata o gestita notificationAt Un rinfresco è arrivato Quella scoperta è iniziata. discoveryStartedAt e discoveryCompletedAt Un aggiornamento limitato è andato dopo il segnale Che tutte le pagine sono state recuperate catena del cursore La paginazione è finita senza spazi Che il cliente ha installato il risultato Digestione registrata scoperta Identificazione dell'insieme completo di definizioni Che una chiamata di strumento avrà successo Digestione del registro dei clienti Identificazione di ciò che il cliente espone attualmente all'agente Che l'agente sceglierà correttamente Costruire la digestione da una proiezione stabile: name , title , description , inputSchema , outputSchema , annotations e execution . Ordina gli strumenti per nome e canonicalizza JSON annidato prima di hashing. Le icone decorative possono essere escluse se non influenzano la selezione o l'esecuzione, ma la proiezione stessa deve essere versione. RFC 8785 spiega perché l'hashing ripetitivo richiede una serializzazione invariante di JSON e una sortazione di proprietà ricorsiva. La classificazione ricorsiva compatta utilizzata in questo esperimento è adeguata ai valori ordinari JSON del dispositivo; non è presentata come un'implementazione completa di JCS. Il codice di produzione dovrebbe utilizzare una libreria di canonicalizzazione rivista, specialmente quando contano casi di bordo numerico o firme. Non memorizzare segreti grezzi nell'istantanea del registro. Gli schemi di strumenti dovrebbero descrivere le forme degli argomenti, non i valori di credenziale. Se una descrizione contiene dati degli inquilini o percorsi interni, redigere prima di raccogliere e registrare quale versione di proiezione ha prodotto il digest. Riproduzione di un audit di registro di sei casi Il dispositivo conservato utilizza sei osservazioni sintetiche: una linea di base completa di due pagine; una rimozione degli strumenti seguita da un aggiornamento completo; una notifica di modifica seguita da nessuna nuova scoperta; pagina uno con un restante nextCursor ; lo stesso nome dello strumento con uno schema di input richiesto modificato; un server che non ha pubblicizzato listChanged , senza prove di aggiornamento limitate. L'ordine decisionale fondamentale è importante: Eseguire il dispositivo con Node.js: Il replay esatto è tornato: I contrasemplari sono più utili dei due casi verdi. notification without refresh ha identiche scoperte e digesti dei clienti, ma la sua scoperta è stata completata prima del segnale di cambiamento. Una coincidenza digestiva con un vecchio snapshot è ancora obsoleta. unfinished pagination ha anche digesti corrispondenti per la pagina osservata, ma nextCursor rimane. Una corrispondenza plausibile di pagina uno è una prova incompleta. Il caso con lo stesso nome cambia read ticket da richiedere solo ticketId a richiedere sia projectId che ticketId . Un inventario di sole nomi definisce il registro invariato. La definizione canonica di digestione cambia da c42521a2412558ca a c3837b93f14b688f , quindi la vecchia definizione del cliente è classificata come obsoleta. Trasforma il verdetto in una decisione operativa Utilizzare converged strettamente. Ciò significa che il registro dei clienti osservato corrisponde a una scoperta completamente traversata completata dopo il segnale di cambiamento pertinente. Non dimostra la disponibilità del trasporto per la prossima chiamata, l'autorizzazione valida, il corretto comportamento dello strumento, un effetto esterno di successo o il risultato previsto dell'attività. Gestire gli altri stati senza automatizzazione aggressiva: Verdicto Le prove Sicuro , prossima mossa . stale Il aggiornamento è più vecchio del segnale, o le digestioni del registro differiscono Smettere di selezionare la definizione interessata; richiedere un aggiornamento limitato; ispezionare prima di riprovare il lavoro conseguente incomplete La scoperta è iniziata , ma manca la prova del percorso del cursore o del completamento . Riprendere dal cursore atteso se il client lo supporta, altrimenti riavviare la scoperta una volta unverifiable Nessuna prova di scoperta limitata esiste Segnalare il segnale come non disponibile; riconnettere o programmare un aggiornamento controllato secondo la politica di runtime converged Scoperta completa dopo il cambiamento e corrispondenza esatta della digestione Continuare, mantenendo i controlli separati di chiamata, effetto e risultato Se il server non ha pubblicizzato listChanged , si prevede silenzio e non si può stabilire freschezza. Definire un'alternativa limitata: aggiornamento al riconnetto, prima di un'esecuzione ad alto impatto, o ad un intervallo misurato che si adatta ai limiti di costo e velocità del server. Registrare tale politica in modo che non si confonda con "nessuna modifica". Inoltre separare la salute del registro dalla salute del compito. Un strumento può essere presente e descritto correttamente finché la sua credenziale è scaduta. Può restituire isError: false mentre il biglietto promesso, file o distribuzione è assente. Dopo qualsiasi recupero approvato, verificare l'effetto esterno o il risultato del compito invece di dichiarare successo perché la scoperta o un comando completato. Preservare il limite del prodotto e dell'autorità Questo controllo appartiene alla osservabilità dell'agente AI perché la disponibilità degli strumenti e la deriva dei permessi possono bloccare i progressi utili mentre l'agente rimane attivo. È un segnale di salute, non un'autorizzazione a riavviare un tempo di corsa, a rotare le credenziali, ad invocare gli strumenti o a ripetere le spese. L'intervento conseguente dovrebbe rimanere limitato, visibile e soggetto all'approvazione umana. La direzione prevista di Sidewisp è uno strato di salute intorno ai tempi di esecuzione degli agenti esistenti: mostrare la prova, la freschezza, la gravità, l'incertezza e la prossima azione più sicura. Il record di convergenza MCP di questo articolo è un modello operativo e un esperimento, non un'affermazione che Sidewisp lo raccoglie attualmente. Sidewisp è attualmente in anteprima privata. Il sito pubblico e il sistema di articoli sono in onda. La raccolta dell'agente di produzione, gli adattatori di runtime MCP, il recupero automatico, la gestione cron e l'analisi dei costi dei token non vengono generalmente spediti. Unisciti all'anteprima privata se vuoi contribuire a plasmare contratti di prova come la negoziazione di protocolli, la convergenza del registro, la disponibilità di strumenti e i risultati verificati mantenendo esplicita l'autorità umana.