La tassa sugli strumenti MCP: paghi la superficie prima ancora di chiedere
Definizioni tool reiniettate a ogni richiesta: 6.726 token per soli 36 tool misurati. Quattro strategie per abbattere la tassa, scelte per contesto d'uso.
Ogni volta che un agente si collega a un server MCP, il client chiama tools/list e riceve, per ciascun tool, una definizione JSON Schema completa: nome, descrizione, parametri, tipi, vincoli. Quella definizione entra nel contesto del modello, viene contata in token e viene reiniettata a ogni nuova conversazione, anche quando l'agente userà un solo tool o non ne userà nessuno.
I maintainer del protocollo l'hanno scritto in chiaro nella roadmap ufficiale: "il modello paga per l'intera superficie prima che l'utente abbia posto una sola domanda" (roadmap MCP). Non è un bug: è il comportamento di default del protocollo, e ora è un cantiere dichiarato sotto il nome di progressive discovery.
La misura in prima persona
Per capire quanto pesa davvero questa superficie, ho catturato tools/list via stdio (JSON-RPC su npx) da tre server ufficiali e contato i token con tiktoken in cl100k_base.
| Server (ufficiale) | Tool | Char | Token |
|---|---|---|---|
server-filesystem | 14 | 12.983 | 2.759 |
server-memory | 9 | 10.760 | 2.288 |
server-everything | 13 | 7.663 | 1.679 |
| Totale | 36 | 31.406 | 6.726 |
Tre soli server, trentasei tool: 6.726 token buttati nel contesto a ogni richiesta, prima che l'utente chieda qualsiasi cosa. In media 187 token per tool.
Il problema è già stato misurato su scala più ampia: l'analisi di LeanZero ha contato 145 tool su 10 server per 40.784 token a richiesta, con l'81,1% del payload occupato da JSON Schema e 3,2 GiB di KV cache bruciati prima che la conversazione inizi. Il paper "Tool Attention" parla di una tassa tra 10k e 60k token per turno sui deployment multi-server (arXiv).
Quattro strategie a confronto
| Strategia | Costo token/richiesta | Latenza | Complessità | Quando conviene |
|---|---|---|---|---|
Schemi ricchi, $defs ripetuti (status quo) | Altissimo: cresce col numero di tool e con la ricchezza degli schemi | Zero | Zero: è il default | Server già in produzione, se il budget token non è un vincolo |
| API avvolte 1:1 | Basso: schemi minimi, zero $defs | Zero | Bassa: un tool per endpoint | Agenti monouso con pochi endpoint noti |
| Discovery differita / lazy loading | Basso: si carica solo il tool che serve | Da bassa a media: una chiamata in più | Media: serve un loader | Agenti multi-server con decine di tool |
| Progressive discovery della spec | Minimo: dedup via $ref e retrieval per embedding | Zero a regime, non ancora disponibile | Dipende dalla spec | Server pubblici serviti a molti client diversi |
La prima riga è lo status quo, ed è il punto da cui si parte. La seconda è una decisione di design: chi espone un tool per endpoint con schemi minimi, senza $defs, abbassa il costo per tool alla fonte. È la leva che controlla chi costruisce il server.
La terza, la discovery differita, è la risposta che Swarms ha già messo in produzione: la release v15 "Akira" dichiara che i suoi 16 tool built-in costano circa 2.600 token a richiesta e introduce un DynamicToolLoader che registra i tool ma li carica solo quando servono (blog Swarms).
La quarta è il cantiere ufficiale annunciato nella roadmap: la progressive discovery. I meccanismi che prefigura, deduplicare gli schemi via $ref e recuperare i tool per embedding invece di inviarli tutti, sono già stati delineati da una proposta del settembre 2025 (SEP-1576), ma una proposta non è una revisione: la spec deve ancora adottarli.
Dove conviene cosa
Non esiste una strategia che vince su tutti i fronti, e chi la propone sta vendendo la propria.
Agente monouso, pochi endpoint. L'avvolgimento 1:1 è la scelta giusta: schemi minimi, costo quasi azzerato, nessuna infrastruttura in più. Il prezzo è rinunciare alla scoperta dei tool a runtime, ma un agente monouso non ne ha bisogno.
Agente multi-server con decine di tool. Qui la tassa diventa il problema: 4 server come i tre che ho misurato, circa 50 tool, costano oltre 9.000 token a richiesta con un tokenizer standard, il 7% di una finestra da 128k, prima ancora della conversazione. Il lazy loading è la risposta migliore oggi: paghi solo i tool che entrano davvero nel contesto.
Il costo è una chiamata in più per risolvere i tool, e la complessità di un loader che decide cosa caricare. Il paper "Tool Attention" misura una riduzione del 95% dei token con questa tecnica, da 47.300 a 2.400, su un benchmark simulato da 120 tool: i numeri end-to-end sono proiezioni dichiarate, ma la direzione è netta (arXiv).
Server pubblico servito a molti client diversi. È il caso che solo la spec risolve: un server non sa in anticipo quale tool un client ignoto vorrà usare, quindi la discovery progressiva con retrieval per embedding è l'unica leva che scala senza sprecare superficie per tutti.
Il vincitore assoluto non esiste, e questa è la conclusione operativa: la scelta dipende da chi paga il conto.
Il conto per tool
I dati pubblicati e la mia misura permettono un confronto che nessuna delle fonti fa direttamente: il costo per tool dei server ufficiali contro quello dei server ricchi. LeanZero pubblica la media dei suoi dieci server: 281 token per tool, con una forchetta da 87 a 898 (LeanZero). I tre server ufficiali che ho misurato stanno a 187 token per tool. Il confronto è approssimativo ma onesto: i due tokenizer sono diversi (LeanZero usa un tokenizer open-weight locale, io cl100k_base), e sui tre server che abbiamo misurato entrambi il suo conta meno del mio, quindi con lo stesso tokenizer il divario con i server ricchi sarebbe ancora più largo.
Il punto non è la media, sono i casi estremi. Notion costa 698 token per tool secondo LeanZero, quasi quattro volte i miei 187, perché ripete 9 $defs in 24 tool (LeanZero). Il costo per tool non è costante e non dipende dal numero di tool: dipende dalla ricchezza dello schema.
Ne segue la conseguenza che regge il confronto: la deduplicazione via $ref fa risparmiare di più proprio sui server più pesanti, quelli che oggi gonfiano la tassa. Sul server snello il taglio è marginale, sul server con gli schemi ripetuti è il 77,7% del payload (LeanZero). Ridurre il numero di tool, al contrario, colpisce la variabile sbagliata: la correlazione tra tool e costo misurata da LeanZero è r = 0,518.
La leva non sta nel ridurre il numero di tool, ma nel ridurre la superficie per tool che si paga. E fino a quando la progressive discovery non sarà nella spec, quella leva è nelle mani di chi costruisce il server: un tool con schema minimo costa 187 token. Un tool con schemi ricchi e $defs ripetuti ne costa quasi 700. La differenza è una decisione di design, non un vincolo del protocollo.
Further Reading
David Soria Parra (Lead Maintainer) and Den Delimarsky (Lead Maintainer)
Mihai Perdum
ChangZeze
Kye Gomez
Kye Gomez
