Osservabilità del MCP: costruire un contratto sanitario a cinque strati

L'osservabilità di MCP dovrebbe rispondere a una domanda più difficile di ha restituito la richiesta? Per ogni sessione del Protocollo di Context Modello, preservare una catena di prove correlata dall'autorizzazione e dall'inizializzazione attraverso la scoperta degli strumenti, l'invocazione, l'effetto esterno e il risultato atteso dell'utente. Una risposta tools/call verde è solo un nodo in quella catena. Il risparmio ragionevole è un contratto sanitario a cinque strati: 1. Session: il client e il server hanno negoziato una versione protocollo supportata e le funzionalità che questa esecuzione utilizzerà? 2. Catalog: Il cliente ha letto l'intera lista degli strumenti attuali e ha reagito a un segnale successivo di modifica dell'elenco? 3. Richiesta: Puoi partecipare alla richiesta di JSON RPC, notifiche di progresso, cancellazione, risposta e scadenza? 4. EEffect: se lo strumento modifica un sistema esterno, ci sono prove di destinazione per ciò che è realmente accaduto? 5. Outcome: l'artefatto, il cambiamento di stato o la decisione che l'agente avrebbe dovuto produrre hanno superato il suo verificatore? Questo contratto separa deliberatamente l'attività del protocollo dal progresso utile. Esso fornisce anche all'operatore uno stato di precisione per il percorso: needs auth , incompatible session , stale catalog , working , protocol error , tool failed , effect unknown , false success o healthy . Inizia con una catena di prove, non con un numero di dashboard. I nuovi risultati statunitensi per l'osservabilità mcp sottolineano sessioni, connessioni, analisi degli strumenti, latenza dei trasporti, throughput e errori. Questi sono utili. L'attuale Documentazione relativa all'osservabilità del MCP di Grafana indica l'istituzione della sessione, la stabilità della connessione, la conformità al protocollo, le prestazioni degli strumenti e l'affidabilità del trasporto. Il divario non è che questi segnali siano sbagliati. La differenza è che nessuno di essi, da solo, prova che il lavoro previsto dall'agente abbia raggiunto la destinazione. Una cartella sanitaria può rimanere compatta: I hash sono identificatori, non il permesso di caricare schemi di strumenti, argomenti, richieste, token o contenuti restituiti. Mantenete valori sensibili sul vostro ospite. Registrare i campi più piccoli necessari per correlare lo stato e dimostrare la decisione. Il contratto dovrebbe anche avere una regola di priorità. Il fallimento dell'autorizzazione avviene prima della salute della sessione; una sessione incompatibile avviene prima della freschezza del catalogo; un catalogo non risolto avviene prima dell'interpretazione della richiesta; un intervallo di tempo di trasporto al confine di un effetto collaterale diventa effect unknown , non un nuovo tentativo automatico; e una chiamata con successo con un consegnabile mancante diventa false success , non sana. Rendere osservabile lo stato del protocollo prima di misurare la latenza dello strumento Il MCP specifica del ciclo di vita rende l'inizializzazione la prima interazione client server. Le due parti concordano una versione del protocollo, scambiano le capacità, e poi entrano in normale funzionamento. Lo stesso documento afferma che la comunicazione successiva deve rispettare la versione e le capacità negoziate. Ciò dà all'osservabilità un primo punto di controllo pulito: memorizzare la versione richiesta, la versione accettata, l'imposta di capacità e il momento in cui il cliente ha inviato notifications/initialized . Non far cadere ogni fallimento prima di quel punto in server down. Per i trasporti HTTP, l'autorizzazione è un cancello separato. L'attuale Specifica dell'autorizzazione MCP definisce la scoperta di risorse protette e richiede ai clienti di gestire una sfida 401 Unauthorized . Un server può essere raggiungibile e corretto mentre il client manca di un token, ha la portata sbagliata o non può scoprire il server di autorizzazione. Rondare come needs auth ; non pagarla come un'interruzione del trasporto. La scoperta degli strumenti ha bisogno di una sua prova di completezza. Il specifica degli strumenti dice che tools/list è paginato e che i server che dichiarano listChanged possono emettere notifications/tools/list changed . Pertanto, abbiamo ricevuto una pagina non è un nuovo catalogo. Registrazione: la capacità di inizializzazione degli strumenti pubblicizzati; ogni cursore di paginazione fino a quando non rimane alcun nextCursor ; un hash canonico di nomi e schemi di input/output; l'ultimo periodo di aggiornamento con successo; ogni notifica tools/list changed e l'aggiornamento che ne è seguito. Questo è più stretto di registrare ogni schema. Un cliente può calcolare il hash localmente e conservare solo il hash, il numero di strumenti, il numero di pagine e l'aggiornamento delle prove. Se arriva una notifica di modifica e il aggiornamento non riesce, classificare la sessione stale catalog . Il server potrebbe ancora rispondere ai ping, ma il modello potrebbe scegliere da un contratto di strumenti obsoleto. Le chiamate di lunga durata introducono un'altra trappola. Il MCP notifiche di progresso utilizza un token fornito mediante richiesta che deve essere unico tra le richieste attive; i valori di progresso devono aumentare e le notifiche devono cessare dopo il completamento. Tale prova può giustificare la working finché la chiamata è entro la scadenza massima. Non dimostra che il lavoro sia utile e non deve mai estendere il termine per sempre. Un messaggio ripetuto senza valore in aumento, un token collegato alla richiesta sbagliata o il progresso dopo una risposta terminale sono prove incoerenti. Utilizzare due orologi: una finestra di inattività, che può essere riposta su un valido progresso monotono; una scadenza massima assoluta, che non si riprende. Questa distinzione impedisce due errori opposti: uccidere il lavoro legittimo perché non è ancora tornato, e accettare un flusso infinito di notifiche di progresso come salute. Una chiamata di strumenti di successo non è il risultato MCP distingue gli errori di protocollo dagli errori di esecuzione degli strumenti. Secondo la specifica degli strumenti, le richieste malformate e gli strumenti sconosciuti utilizzano errori JSON RPC, mentre i guasti di business o di input possono restituire un risultato degli strumenti con isError: true . Tenere tali stati separati perché la prossima azione è diversa: fissare il contratto client per protocol error ; regolare le entrate, le autorizzazioni o la dipendenza downstream per tool failed . Il caso più pericoloso è l'assenza di reazione dopo un effetto collaterale. Supponiamo publish report volte fuori. Riprovare immediatamente può creare un rapporto duplicato perché l'incertezza dei trasporti non dice nulla sulla destinazione. Segnalare la chiamata effect unknown , conciliare utilizzando una chiave di operazione stabile o una query di destinazione e riprovare solo dopo che le prove dimostrino che il primo tentativo non è stato commesso. Anche un risultato normale non è sufficiente. Il server può restituire isError: false mentre il file promesso è assente, il record remoto è ancora un disegno o l'URL è privato. Aggiungere un verificatore di risultato scelto prima della chiamata: hash di file, riga di database più versione, stato HTTP pubblico, risultato del test o altra ricevuta deterministica. Utilizzare un giudice LLM solo quando il risultato non può essere verificato direttamente e etichettare le prove più deboli. Questo crea tre stati distinti che sembrano terminali: Risultato del protocollo Effetto di destinazione Esito atteso Stato sanitario tempo di lavoro sconosciuta sconosciuta effect unknown successo verificato fallito o mancante false success successo verificato verificato healthy La fila media conta di piu'. Essa impedisce che uno scambio di protocollo di successo diventi una falsa affermazione che l'agente ha completato il compito dell'utente. Riproduci il contratto contro casi inconvenienti L'artefatto di accompagnamento è un dispositivo illustrativo di nove casi e un classificatore deterministico. Non contiene telemetria di produzione. Fate partire con: Il dispositivo copre una sana esportazione e otto confini inconvenienti: una sfida di autorizzazione, una versione del protocollo non supportata, una modifica non concordata dell'elenco degli strumenti, una chiamata di lunga durata con un valido progresso, una chiamata malformata, un errore di esecuzione degli strumenti, un timeout dopo un possibile effetto collaterale e un successo con un prodotto mancato. Il classificatore ha restituito un caso in ogni stato previsto: Questa è la parte falsificabile del metodo: cambiare le prove e lo stato deve cambiare in modo prevedibile. Se il tools/list changed è seguito da un aggiornamento completo, il caso di catalogo obsoleto dovrebbe avanzare. Se la chiamata in ritardo ottiene una ricevuta di destinazione ma il suo verificatore di consegna non riesce, essa dovrebbe passare da effect unknown a false success . Essa raggiunge healthy solo quando la sessione, il catalogo, la richiesta, l'effetto e le prove di risultato sono tutti d'accordo. L'artefatto non conferma la correttezza della semantica aziendale di uno strumento. Non scopre un effetto collaterale non documentato, non dimostra che un emittente di OAuth sia affidabile o non decide quanto tempo dovrebbe essere il termine. Queste sono revisioni specifiche per l'impiego. Il suo compito è più piccolo: impedire che le prove mancanti vengano silenziosamente rese verdi. Avviso sullo stato che ha bisogno di un'azione Non mandare tutti gli stati non sani nello stesso canale. needs auth va al titolare della credenziale o dell'autorizzazione con la risorsa contestata e la portata richiesta, mai il valore del token. incompatible session va al proprietario dell'integrazione con versione client, versione server e funzionalità negoziate. stale catalog innesca un tentativo di riscoperta limitata; il fallimento ripetuto diventa un incidente di integrazione. working rimane silenzioso finché il progresso è valido e il termine assoluto rimane. protocol error va all'implementatore cliente con il metodo, l'identificatore di richiesta e la classe di errore disinfettato. tool failed segue la politica di riprova dello strumento solo quando si sa che il guasto è reversibile. effect unknown blocca automaticamente la riprova al confine dell'effetto collaterale e inizia la riconciliazione. false success apre un incidente risultante anche se il MCP stesso è completato. Questo routing mantiene waiting distinto da stuck. Un prompt di autorizzazione assegnato a una persona può essere una legittima attesa; un token di progresso che avanza all'interno di una richiesta limitata può essere un lavoro; un catalogo invariato dopo un segnale di cambiamento di lista non è né. Inizia con un unico strumento di alto valore e un vero verificatore di risultati. Captura la catena per una settimana, ispeziona ogni stato sconosciuto, poi aggiungi copertura. Un dashboard perfetto per tutta la flotta costruito su eventi non correlati è meno utile di un'unica chiamata di strumento la cui sessione, effetto e risultato possono essere spiegati da capo a capo. Quando questo contratto cessa L'osservabilità MCP può stabilire protocolli e prove operative, ma non può dedurre tutte le intenzioni dell'utente dal filo. Uno schema di uscita valido dimostra la forma, non la verità. Un ricevimento di destinazione dimostra un effetto, non che l'effetto sia stato saggio. Un segnale di progresso monotono dimostra il movimento segnalato dal server, non un progresso utile verso l'obiettivo dell'utente. Tali confini richiedono controlli di applicazione e talvolta giudizio umano. Sidewisp è attualmente in anteprima privata. Gli adattatori di monitoraggio della produzione e i sistemi di recupero non vengono generalmente spediti. Il contratto di cui al presente articolo è un metodo operativo e un artefatto locale ispezionabile, non una affermazione che Sidewisp raccolga già le sessioni MCP o le ripara. L'orientamento del prodotto previsto è quello di rendere più facile vedere le prove di salute, l'incertezza e i confini di approvazione al fianco dei tempi di esecuzione esistenti. Se stai progettando un'integrazione MCP ora, mantenere il registro a cinque strati locale, modificare il contenuto e rifiutare di chiamare una corsa sana fino a quando il risultato previsto non avrà il suo ricevimento. Quella regola unica trasforma la telemetria del protocollo in una decisione operativa invece di un altro grafico verde.