Tool search tool di Claude e il peso degli MCP

Da qualche mese Claude non carica più le descrizioni complete degli strumenti dei server MCP all’apertura della conversazione, ma solo i loro nomi, e va a cercare le schede quando servono. Su una configurazione con 18 server e 198 strumenti la differenza è fra 110.400 token e 6.900. L’articolo spiega come funziona il meccanismo, perché è una funzione di Claude e non dello standard MCP, cosa continua a costare e cosa cambia nella pratica per chi collega servizi esterni all’assistente.

198 strumenti collegati, due usati

Per scrivere questo articolo mi sono messo nella condizione dell’utente medio, attivando un buon numero di server MCP. Poi ho aperto il pannello che misura l’occupazione della finestra di contesto, dentro Claude Code nell’applicazione desktop.

Gli strumenti collegati erano 198, e caricati per intero avrebbero occupato 110.400 token del contesto, ne occupavano invece 6.900 con gli altri 103.500 che comparivano sotto la voce deferred, differiti, presenti nell’inventario e assenti dalla memoria di lavoro.

Nel corso della ricerca ne ho usati due.

Quel rapporto fra quello che c’era e quello che pesava è il segno di una funzione arrivata nei prodotti Claude fra la fine del 2025 e l’inizio del 2026.

Un server, molti strumenti

Partiamo da un numero, 198, non sono 198 server MCP diversi.

MCP è lo standard che permette di collegare un assistente a servizi esterni, e un server MCP è il pezzo di software che fa da tramite verso uno di quei servizi. Il server però non è un blocco unico. Espone al modello un elenco di azioni distinte, chiamate strumenti nella traduzione italiana e tool nella documentazione, e ogni azione è separata dalle altre.

Il server di Gmail non offre «Gmail», offre la ricerca dei thread, la lettura di un singolo messaggio, la creazione di una bozza, l’applicazione di un’etichetta e altro ancora, ciascuna come voce a sé. Ogni voce porta con sé un nome, una descrizione di cosa fa e di quando conviene usarla, e l’elenco dei parametri che accetta con il formato di ciascuno. È una scheda tecnica in miniatura, scritta in linguaggio naturale perché a leggerla è il modello.

Quante schede porti un server dipende da come è stato scritto. Fra i miei, quello di Canva ne espone oltre trenta. Quello di Unstructured Transform, che serve a estrarre dati da documenti, ne espone sette. I 18 server che avevo acceso sommavano 198 tool con, ovviamente, altrettante schede di descrizione testuale.

L’affitto che pagano gli strumenti

Quelle schede occupano spazio nella finestra di contesto. È lo spazio finito dentro cui il modello tiene tutto quello che gli serve per rispondere, le istruzioni ricevute, la conversazione fatta fino a quel momento, i documenti aperti.

Nel protocollo è previsto che le schede vengano consegnate tutte all’apertura della sessione, prima che l’utente scriva una parola. Il costo non dipende dall’uso, perché sta nella presentazione e non nell’attività. Un server collegato e mai chiamato pesa quanto un server usato in continuazione.

Quanto pesi si vede con un conto controfattuale sui miei numeri. La sessione da cui ho preso la misurazione ha una finestra da un milione di token, una dimensione estesa che non è quella ordinaria, e lì i miei 198 strumenti avrebbero occupato poco più di un decimo dello spazio. Su una finestra da 200.000 token, che è la misura con cui lavora la maggior parte delle persone, ne avrebbero occupato più della metà.

L’ovvia misura è quella di collegare solo i server che servono davvero, non per prudenza ma per puro calcolo matematico. Un articolo del settembre 2025 riporta che il solo server di Playwright, usato per automatizzare il browser, occupava da solo circa un quinto della finestra di Claude Sonnet 4. Altri ambienti all’epoca avevano risolto la cosa a colpi di tetto massimo, con un numero fisso di strumenti oltre il quale non si poteva andare.

Cosa succede oggi

Invece di consegnare tutte le schede all’avvio, il sistema ne consegna solo i nomi, e tiene le schede complete da parte. Quando il modello ha bisogno di uno strumento, lo individua attraverso il nome e in quel momento la scheda corrispondente entra nel contesto. Anthropic ha chiamato questa funzione Tool search tool, cioè uno strumento che serve a cercare gli strumenti.

I 6.900 token che nel mio caso restavano in contesto sono esattamente questo, i nomi dei 198 strumenti e nient’altro. Le descrizioni e i parametri stavano nei 103.500 differiti, fuori dalla memoria di lavoro finché non fosse servito.

La ricerca funziona in due modi, a scelta di chi costruisce l’applicazione. Uno confronta la richiesta con i nomi degli strumenti attraverso una corrispondenza testuale, l’altro usa una ricerca in linguaggio naturale che pesa anche le descrizioni. In entrambi i casi la ricerca restituisce un piccolo gruppo di candidati, massimo cinque per impostazione predefinita, e solo le loro schede vengono aggiunte alla conversazione.

Le skill hanno un funzionamento simile, anche lì il sistema conosce fin dall’inizio i nomi e le descrizioni brevi, e va a leggere le istruzioni complete solo quando decide che quella competenza serve. La novità non sta nell’idea, che circolava già, ma nel fatto che sia stata applicata agli strumenti esterni, dove il costo era molto più alto.

Non è il protocollo, è Claude

Il caricamento differito degli strumenti non ha mai fatto parte della specifica del protocollo MCP, che prevede un solo modo di scoprire gli strumenti di un server, una richiesta che si chiama tools/list e che restituisce l’elenco completo. La sezione della specifica dedicata agli strumenti, nella versione del giugno 2025, dice in traduzione che «per scoprire gli strumenti disponibili i client inviano una richiesta tools/list». Il client, nel gergo del protocollo, è il programma che si collega al server, cioè l’applicazione che l’utente ha davanti, Claude Desktop, Claude Code, Cursor o un’altra ancora. L’unica opzione accessoria prevista è la paginazione, cioè la possibilità di ricevere l’elenco a blocchi invece che tutto insieme. Non esiste un parametro di ricerca, non esiste un filtro, non esiste modo di chiedere al server solo gli strumenti che servono.

La versione più recente della specifica, pubblicata il 28 luglio 2026, non ha cambiato questo punto. Ha modificato parecchie altre cose, dalla gestione delle sessioni all’autenticazione, e sulle liste ha aggiunto due parametri che riguardano la conservazione temporanea delle risposte, non la ricerca.

Il problema è comunque riconosciuto. Nel repository ufficiale del protocollo giacciono quattro proposte che tentano di risolverlo, una che aggiungerebbe una query alla richiesta di elenco, una che filtrerebbe in base ai permessi concessi, una che introdurrebbe gruppi ed etichette, una che porterebbe nel protocollo lo stesso principio a livelli delle skill. Nessuna delle quattro è stata accolta, tutte sono ferme allo stato di bozza, e l’ultima cita come ispirazione dichiarata proprio il documento con cui Anthropic ha presentato la sua funzione. La direzione di influenza va dal fornitore verso lo standard, non il contrario.

La distinzione è diventata più netta da quando, nel dicembre 2025, MCP è stato donato alla Agentic AI Foundation, un fondo diretto dalla Linux Foundation, dove Anthropic siede accanto a OpenAI, Google, Microsoft, Amazon e altri come membro fra pari. Attribuire allo standard aperto una funzione che uno dei membri ha costruito sopra di esso è scorretto due volte.

Che non sia una proprietà del protocollo si vede anche dal fatto che ognuno se l’è costruita per conto proprio, con un nome diverso.

• Anthropic la chiama Tool search tool e la esegue sui propri server (da non confondere con il server MCP), non su quelli di chi la usa;
• OpenAI la chiama tool search e adotta lo stesso identico parametro per marcare gli strumenti da differire;
• GitHub Copilot la chiama Virtual Tools e raggruppa gli strumenti simili sotto etichette che l’assistente apre quando servono;
• Cursor la chiama scoperta dinamica del contesto e sincronizza le descrizioni su una struttura di file che il modello legge quando decide di leggerla, con una riduzione dichiarata di quasi la metà dei token complessivi.

Nessuno dei quattro l’ha inventata. L’idea di rendere ricercabile lo strumento adatto in una lista per poi caricarlo, invece di caricarli tutti preventivamente, circola nella ricerca sul function calling almeno dall’aprile del 2023, diciannove mesi prima che MCP esistesse. Anthropic dal canto suo dichiara le proprie ispirazioni in fondo al documento con cui ha presentato la funzione, «We also drew inspiration from across the AI ecosystem, including Joel Pobar’s LLMVM, Cloudflare’s Code Mode and Code Execution as MCP». I primi due arrivano allo stesso risultato per un’altra via, perché LLMVM e Code Mode fanno scrivere al modello del codice che usa gli strumenti invece di consegnargli le loro descrizioni, ma partono dallo stesso principio, cioè lasciare che sia il modello ad andarsi a prendere quello che gli serve invece di dargli tutto in anticipo. Il terzo è un post di Anthropic stessa di venti giorni prima, dove quel principio ha un nome, progressive disclosure, e dove una riga propone già la soluzione, «a search_tools tool can be added to the server to find relevant definitions». Il Tool search tool è quella riga diventata prodotto.

Le conseguenze pratiche sono due. La prima riguarda chi scrive i server MCP, che non deve fare nulla perché il meccanismo vive interamente dalla parte del client. I server già in circolazione ne traggono vantaggio senza che i loro autori debbano intervenire, e questo spiega perché la funzione si sia diffusa in fretta.

La seconda riguarda chi i server li usa, ed è meno comoda, perché a decidere se differire o no sono le aziende che sviluppano i vari client, Anthropic per Claude Desktop e Claude Code, Microsoft per Visual Studio Code, e così per le altre. All’utente resta la scelta fra le opzioni che il suo programma gli mette a disposizione, non quella di aggiungere una funzione che lì non c’è. Gli stessi 18 server della mia configurazione, aperti con un client che non implementa nulla del genere, tornerebbero a occupare tutto il loro peso.

Chi deve fare cosa

In Claude Code il caricamento differito è attivo di suo, senza che nessuno debba attivarlo.

Tool search is enabled by default. MCP tools are deferred rather than loaded into context upfront, and Claude uses a search tool to discover relevant ones when a task needs them. Only the tools Claude actually uses enter context. From your perspective, MCP tools work exactly as before.

L’ultima frase dice che chi ha collegato dei server mesi fa e continua a lavorare come sempre non si è accorto di nulla, il cambiamento è avvenuto dietro le quinte.

In Claude Desktop il comportamento generale si imposta dalle impostazioni, sotto Funzionalità, alla voce «Modalità di accesso agli strumenti», che dichiara di controllare come vengono caricati gli strumenti del connettore nelle nuove conversazioni. Le opzioni sono due. Con «Carica strumenti quando necessario» le schede restano differite, e l’interfaccia spiega il vantaggio così, «le chat si comprimono meno poiché gli strumenti non sono precaricati». Con «Strumenti già caricati» succede il contrario, e l’avvertenza diventa «le chat si compattano più spesso poiché gli strumenti sono sempre presenti».

Quella parola, compattazione, è il momento in cui una conversazione troppo lunga viene riassunta per poter continuare la discussione, bisogna ricordare che questa operazione comporta il rischio di perdita di dettaglio.

Quello che continua a costare

Il caricamento differito non azzera il conto, lo riduce e qualcosa entra nel contesto dal primo istante.

Restano i nomi degli strumenti, che sono i 6.900 token della mia configurazione. Restano le istruzioni del server, cioè quel breve testo con cui un server MCP spiega a cosa serve e quando conviene cercarlo, che ha preso importanza proprio perché è l’unica cosa che il modello legge sempre. E c’è un limite di lunghezza, perché Claude Code tronca a due kilobyte ciascuna sia le istruzioni del server sia le descrizioni dei singoli strumenti, con la raccomandazione di tenerle brevi e di mettere le informazioni importanti all’inizio.

Da quanti server a quali strumenti

La documentazione di Claude Code descrive oggi il limite in questi termini.

Tool search keeps MCP context usage low by deferring tool definitions until Claude needs them. Only tool names and server instructions load at session start, so adding more MCP servers has minimal impact on your context window. Claude Code doesn’t impose a fixed per-server tool cap; the practical limit is your context window budget.

Il vincolo si è spostato dal numero di server allo spazio disponibile. La raccomandazione di disattivare i server che non si usano resta nella pagina dedicata ai costi, insieme al suggerimento di preferire i comandi da terminale dove esistono, perché quelli non aggiungono nessun elenco di strumenti. La motivazione però è diversa da prima, perché quello che si risparmia disattivando un server non sono più le sue schede, sono i nomi dei suoi strumenti e le sue istruzioni. Il senso dell’avere attivi il minimo necessario dei server MCP sta nella pulizia dell’ambiente, sia per evitare di averne di non utilizzati e quindi caricati inutilmente, sia per evitare sovrapposizioni più o meno parziali di funzionalità che potrebbero portare a scelte di tool non corrette.

Se di un server che ne espone trenta ne serve uno entra quello, e questo meccanismo funziona fino ai cinque strumenti a cui può arrivare la risposta della ricerca. Lo si verifica nel proprio pannello, espandendo l’elenco degli strumenti dopo una sessione di lavoro, dove compaiono caricati due o tre nomi su alcune centinaia.

Il conto perciò si compone in due tempi. All’apertura è prevedibile e uniforme, perché ogni strumento vale il suo nome e nient’altro. Durante il lavoro cresce di una scheda alla volta, e le schede non si equivalgono. Ai due estremi della mia configurazione stanno lo strumento di Canva che modifica un progetto grafico e quello di Gmail che applica un’etichetta a un messaggio, e fra i due corrono più di venti volte. Fanno lavori di complessità molto diversa, quindi quel rapporto non misura uno spreco, misura quanto è ampia la scala.

La stessa ampiezza si ritrova in una misurazione indipendente di luglio 2026, che ha aperto nove server diffusi e ne ha contato le definizioni con un metodo dichiarato. Gli strumenti dei server più verbosi costano in media otto volte quelli dei server più asciutti. Una parte della differenza dipende da cosa fanno, un’altra da come sono descritti, e solo la seconda è quella su cui qualcuno potrebbe intervenire.

Quel costo si paga a ogni sessione in cui lo strumento serve, quindi si moltiplica per l’uso invece che per il numero di server collegati. È il rovesciamento rispetto a prima, quando un server pesante e mai chiamato pesava esattamente quanto un server pesante e usato di continuo.

Le descrizioni di un server altrui non si riscrivono, quindi la leva vera ce l’ha chi i server li costruisce. Prefissi coerenti per servizio, così che una ricerca sola catturi l’intero gruppo. Nomi specifici invece che generici, con l’esempio che la documentazione dell’Agent SDK porta direttamente, dove search_slack_messages viene trovato per una gamma di richieste più ampia di query_slack. Descrizioni brevi con parole chiave specifiche («Cerca messaggi Slack per parola chiave, canale o intervallo di date») rispondono meglio alle query rispetto a quelle generiche («Interroga Slack»).

I limiti

Il meccanismo ha un costo suo. La ricerca è un passaggio in più prima di ogni chiamata, quindi aggiunge tempo, e sotto la decina di strumenti collegati Anthropic stessa la dichiara poco utile, perché il tempo che si perde a cercare vale più dello spazio che si risparmia.

C’è poi un modo di sbagliare che prima non esisteva. Se il nome e la descrizione di uno strumento non somigliano a come la richiesta è stata formulata, la ricerca può non trovarlo, e il modello lavora senza uno strumento che avrebbe potuto usare. Con tutte le schede caricate il problema non si poneva, perché erano già tutte lì.

In pratica

Nella maggior parte dei casi l’utente non deve fare nulla, perché il caricamento differito è già attivo per impostazione predefinita sia in Claude Code sia nell’applicazione desktop.

Chi vuole verificare come stanno le cose sulla propria macchina può farlo con il comando /context in Claude Code (sia nel terminale che in Claude Desktop) e dalla conversazione nell’applicazione. Espandendo l’elenco degli strumenti si legge quanti sono, quanto pesano e quali sono stati caricati, ed è il posto dove si vede se un server occupa più di quanto valga.

L’impostazione generale nell’applicazione desktop conviene lasciarla com’è, salvo un caso. Chi ha pochi connettori e li usa tutti a ogni conversazione può passare al caricamento immediato, perché lì il passaggio di ricerca è un ritardo senza contropartita.

Del vecchio consiglio resta valida la parte che riguarda l’igiene della configurazione, cioè disattivare i server che non si usano più. Quello che non vale più è il calcolo che stava dietro, perché collegare un server in più non costa quanto costava.

Prima di collegare qualcosa di nuovo la domanda utile riguarda quanto lo si userà. Un server che serve una volta al mese costa poco anche se è scritto male, uno che serve in ogni sessione paga il proprio peso ogni volta.

Un vincolo in meno

I server che avevo acceso per scrivere questo articolo erano 18, gli strumenti 198, quelli serviti due. Prima del caricamento differito quella configurazione avrebbe chiesto 110.400 token solo per presentarsi, con il differimento ne ha chiesti 6.900.

Non è un invito a collegare tutto quello che capita, perché la ricerca aggiunge un passaggio prima di ogni chiamata, le istruzioni dei server restano in contesto anche quando i loro strumenti non servono, e sotto la decina di strumenti il meccanismo è dichiarato poco utile dalla stessa azienda che lo ha costruito. È però la fine di un vincolo che pesava sulla configurazione di chiunque avesse collegato più di due o tre servizi, e che nessuno poteva aggirare.