Utilizzo dei token MCP: Misurazione di quattro bacini per risultato

L'utilizzo dei token MCP deve essere misurato per risultato verificato , non per server, chiamata strumento o chat. Il totale utile è l'input consumato in ogni chiamata di modello necessaria per produrre il risultato richiesto, suddiviso in quattro secche: istruzioni di base, schemi di strumenti esposti, storia della scoperta e carichi utili dei risultati degli strumenti. Confronta i candidati all'ottimizzazione solo dopo che ciascuno ha prodotto lo stesso ricevimento di risultato. Questa regola evita due errori comuni. Un totale di sessioni del fornitore non può dirti se gli schemi o i risultati hanno causato la crescita. Un piccolo numero di token può sembrare efficiente anche quando l'agente ha scelto lo strumento sbagliato o ha omesso il consegnabile. Prima contare, preservare il contratto di risultato, poi cambiare una superficie alla volta. Costruire un libro più grande di quattro bucket prima di ottimizzare Il Specifica degli strumenti MCP definisce tools/list per la scoperta e dà a ogni strumento un nome, una descrizione e uno schema di input. Un cliente può trasformare la risposta prima di presentare gli strumenti a un modello, in modo che MCP stesso non carichi token. La richiesta di modello creata dal cliente è ciò che conta. Per un compito, registra: Cucina Che cosa ne appartiene. Perché cresce? Linea di base istruzioni del sistema, attività dell'utente, confezionamento della richiesta ripetuto in ogni chiamata di campionamento Schemi nomi degli strumenti, descrizioni, schemi di input, annotamenti che il cliente espone più strumenti, descrizioni verbali, esposizione ripetuta Scoperta corrispondenze di ricerca, descrizioni degli strumenti selezionati, giri di scoperta precedenti la divulgazione progressiva aggiunge viaggi di andata e ritorno Risultati Uscite degli strumenti conservate nella cronologia dei messaggi carichi utili e riattaccamento ripetuto Somma ogni secchio lungo il percorso completo fino ad un risultato: Tenere le letture della cache del provider, le scritture della cache, i token di uscita, la latenza e il prezzo nelle colonne adiacenti. Non mescolarli silenziosamente nei quattro secchi di ingresso. Rispondono a domande diverse. Un schema memorizzato in cache può costare meno a un fornitore mentre occupa ancora il contesto e ha ancora bisogno di controlli di freschezza. Definire la ricevuta del risultato prima della misurazione. Per l'esperimento di seguito, il compito era: restituire il tasso di errore dell'API di pagamento corrente, il tempo di osservazione e la fonte di prove. Una corsa passava solo quando esistevano tutti e tre i campi: Questo è intenzionalmente più rigoroso di quanto non sia stato fatto con successo. Un successo a livello di trasporto senza tempo di osservazione potrebbe essere obsoleto. Una percentuale senza fonte di prove non può essere indagata. L'output compatto è utile solo quando conserva i campi necessari per la prossima decisione. Conteggi la richiesta esatta, non un rapporto di testo indovinato Utilizzare il contatore del fornitore di destinazione con lo stesso modello, il prompt del sistema, i messaggi e gli strumenti che intendi inviare. Anthropics documentazione di conteggio dei token afferma che l'endpoint accetta gli stessi input strutturati di una richiesta di messaggio, compresi gli strumenti. Esso etichetta anche il risultato come stima e consiglia di contare sul modello previsto. Una richiesta di previazione può sembrare così: Non mettere mai la chiave nel dispositivo JSON o in un rapporto. Salvare il conteggio di input restituito con l'identificatore del modello, il tempo di contatto, l'hash della richiesta, il conteggio degli strumenti esposti, il numero di chiamata e l'ID di risultato. Eseguire il contatore una volta per la richiesta di linea di base, quindi di nuovo dopo ogni turno di modello/strumento perché la scoperta e la cronologia dei risultati cambiano il successivo input. Se il tuo provider non ha un contatore, usa un tokenizer locale fissato come proxy di confronto, non come fatturazione. Tieni fissato il serializzatore e la versione del tokenizzatore. Il dispositivo per questo articolo utilizza js tiktoken 1.0.21 con cl100k base ; che è riproducibile attraverso i suoi tre scenari, ma non è un tokenizer Claude. Le percentuali di seguito indicano la forma relativa dell'apparecchio, non un risparmio MCP universale. Che cosa misurò il dispositivo di 40 strumenti L'artefatto ispezionabile crea 40 strumenti operativi sintetici. Uno strumento restituisce la prova dell'errore di pagamento richiesto; gli altri 39 hanno nomi, descrizioni e schemi JSON realistici, ma sono irrilevanti per questo compito. Confronta tre percorsi: 1. esporre tutti e 40 gli schemi e mantenere un risultato verbo; 2. espone solo lo strumento conosciuto e conserva un risultato compatto; 3. espone search tools , describe tools e execute tool , poi scopre uno schema e conserva il risultato compatto. Ogni percorso passava la stessa ricevuta a tre campi. Le entrate proxy misurate sono state: Scenario Chiamate Linea di base Schemi Scoperta Risultati Complesso Risparmio : : : : : : : Strumenti statici 40, risultato verbo 2 110 8,768 0 625 9,503 linea di base Strumento selezionato, risultato compatto 2 110 188 0 55 353 96.3% Scoperta dinamica, risultato compatto 4 220 572 309 55 1,156 87.8% L'osservazione dominante è l'attribuzione, non la percentuale di titolo: gli schemi ripetuti hanno contribuito a 8.768 dei 9.503 token proxy nel percorso statico. Trimming il risultato da solo non avrebbe riparato quel carico di lavoro. Al contrario, quando lo strumento corretto era già conosciuto, il percorso a uno strumento batteva la scoperta dinamica perché la scoperta raddoppiò il numero di chiamate di modello e aggiunse 309 token di storia. Il dispositivo e il contatore sono sufficientemente piccoli da controllare: Riproduci la struttura con le tue vere definizioni di strumento, ma sostituisci il proxy con il contatore del tuo provider prima di impostare una soglia di costo o di finestra di contesto. Rimpiazzare anche la ricevuta di successo sintetica con un controllo deterministico del tuo effettivo derivato o esterno. Questi risultati concordano con la direzione di una Indice di riferimento Speakeasy toolset dinamico più grande: l'esposizione progressiva degli strumenti può ridurre notevolmente l'ingresso dello schema statico, ma richiede più chiamate degli strumenti e può aumentare la latenza. Le loro percentuali provenivano dai loro set di strumenti, dai loro compiti e dal loro modello. Non sono una promessa per voi. Scegli il controllo dal secchio più grande Utilizzare il libro di contabilità per scegliere un intervento: Se gli schemi dominano e lo strumento richiesto è noto dal contesto di routing, espone un sottogruppo consentito. Se i schemi dominano ma lo strumento non è noto, testare la ricerca dinamica e la descrizione contro i casi di errore di recupero. Se i risultati dominano, proiettare solo campi rilevanti per la decisione e mantenere la freschezza, la copertura, gli errori e i riferimenti alle prove. Se la linea di base è dominante, abbreviare le istruzioni ripetute o separare la politica stabile dal contesto specifico del compito. Se la scoperta domina, migliorare il routing, riutilizzare una selezione a scopo sicuro, o accettare un sottoinsieme statico più grande. Non iniziare con installare un ottimizzatore di token. Inizia con il secchio e il compito. Una superficie CRM di quaranta strumenti può giustificare la scoperta progressiva. Un controllo di salute che richiama sempre uno strumento metrico conosciuto solo per lettura probabilmente non lo fa. Per la scoperta dinamica, fallire i test con la stessa aggressività dei risparmi. Includere termini ambiguo utente, nomi di strumenti quasi duplicati, strumenti non disponibili, perdita di autorizzazioni, elenchi di strumenti obsoleti e una query che non dovrebbe selezionare alcun strumento. Misurare l'accuratezza della selezione e il tempo P95 fino al risultato verificato. La fase di ricerca aggiuntiva vale la pena solo quando la riduzione dello schema supera il suo costo di recupero e di latenza. La compressione del risultato ha bisogno di un suo limite. Conservare identificatori, unità, tempo di osservazione, copertura, stato di errore e un riferimento alle prove ogni volta che influenzano la prossima azione. Evitare i registri completi, la prosa duplicata, i metadati non utilizzati e i registri grezzi. Se un risultato compatto rimuove il motivo per cui un operatore può fidarsi o riprodurre un verdetto, si tratta di perdita di dati. Utilizzare una semplice porta promozionale: Imposta gli obiettivi dal tuo carico di lavoro piuttosto che copiare il dispositivo. Invertire se la qualità del risultato, la selezione degli strumenti, la freschezza o la verifica si riducono. Più token non è un segnale di recupero e una chiamata MCP completata non è la prova che il lavoro previsto sia avvenuto. Tenere esplicito il limite sanitario La crescita dei token può indicare schemi ripetuti, risultati di strumenti di dimensioni eccessive, ripetizioni o accumulo di contesto. Può anche essere legittimo: un nuovo strumento diventa necessario, un'indagine ha bisogno di prove, o l'agente sta aspettando piuttosto che circolare. Interpretare il libro più grande accanto al progresso utile e al risultato atteso. Sidewisp è attualmente in anteprima privata. La sua direzione del prodotto include l'efficienza del tempo e del budget come un segnale di salute dell'agente, ma è prevista la raccolta e l'ottimizzazione dell'utilizzo dei token in diretta; questa capacità non è attualmente distribuita. Il passo pratico ora è tenere il proprio libro dei risultati, conservare le prove e testare una variazione di esposizione al MCP alla volta. La decisione è quindi concreta: utilizzare l'esposizione selezionata per un percorso stabile con uno strumento noto, la scoperta dinamica per una grande superficie incerta che supererà le prove di recupero e la proiezione dei risultati quando la cronologia del carico utile è il costo reale. Pubblicare la modifica solo dopo che la ricevuta dello stesso risultato è ancora in corso.