Più strumenti per gli agenti AI, più spazio occupano le loro descrizioni: il paradosso del protocollo dati.
Cinque giorni fa, il 25 agosto, un paper sottomesso su arXiv ha mostrato un dato che a prima vista sembra un refuso: in un agente AI che usa il protocollo MCP per accedere a strumenti esterni, il 70,1% del contesto era consumato dalla semplice elencazione degli strumenti disponibili. 140.200 token. Il sistema descritto nel paper, chiamato SCOUT e già in produzione presso PayPal, li riduce a 1.300 — lo 0,8% del contesto. Una riduzione del 99%, con un taglio del costo per singola query su scala aziendale.
Per capire perché questo numero conta, serve un passo indietro. MCP (Model Context Protocol) è uno standard aperto e universale per connettere i sistemi AI con le fonti di dati, nato per sostituire integrazioni frammentate con un unico protocollo. Il meccanismo è semplice: l’agente riceve un elenco degli strumenti disponibili, ognuno con una descrizione, e da lì decide quale usare. Le descrizioni occupano spazio nel contesto — lo spazio di lavoro del modello, che ha un costo in calcolo e denaro. Più strumenti ci sono, più descrizioni finiscono nel contesto. E più descrizioni ci sono, meno spazio resta per ragionare sul compito vero e proprio.
Il 70% del contesto sprecato: il dato che rompe l’incantesimo dell’AI agentica
Il numero SCOUT rovescia un assunto ormai diffuso: che dare più strumenti a un agente lo renda automaticamente più capace. Non è così. Ogni strumento aggiuntivo porta con sé una descrizione che deve essere letta, valutata, confrontata. Quando il numero cresce, la descrizione degli strumenti diventa essa stessa il collo di bottiglia. Il 70,1% del contesto sprecato non è un caso limite: è la fotografia di un agente che passa più tempo a capire cosa ha a disposizione che a fare il lavoro per cui è stato chiamato.
Resta la domanda che il paper lascia aperta: come mai un protocollo pensato per semplificare le integrazioni ha prodotto questa inefficienza? La risposta non sta nella cattiva volontà di un singolo sviluppatore, ma nell’architettura stessa del sistema.
Il paradosso di MCP: più standard, più rumore
L’adozione di MCP è cresciuta rapidamente. Già a dicembre 2025, un anno dopo il lancio, Anthropic aveva donato il protocollo alla Linux Foundation, e a quel punto c’erano più di 10.000 server MCP pubblici attivi. Il paper SCOUT descrive un’architettura proxy che aggrega più server backend dietro un singolo endpoint — e parla esplicitamente di una barriera di scopribilità, la difficoltà di trovare e identificare lo strumento giusto: oltre 2.000 strumenti indicizzati su più di 200 server MCP, in cui utenti e agenti faticano a distinguere il migliore.
Il paradosso è evidente: MCP doveva semplificare le integrazioni, ma la sua stessa diffusione ha creato un problema nuovo. Un agente con accesso a 2.000 strumenti non è necessariamente più capace di uno con accesso a 200. È semplicemente più disorientato.
Il contesto è una risorsa finita: la prossima sfida per chi costruisce agenti
Non è una questione accademica: è già un problema di business. Anthropic lo dice da tempo: il contesto deve essere trattato come una risorsa finita, con rendimenti marginali decrescenti. E secondo la stessa Anthropic, ha osservato definizioni di strumenti che consumano 134.000 token prima dell’ottimizzazione. Sono ordini di grandezza simili a quelli riportati nel paper SCOUT.
A rendere il problema più acuto c’è la qualità delle descrizioni. Un’analisi separata, pubblicata anch’essa su arXiv, ha rilevato che il 97,1% delle descrizioni degli strumenti analizzati contiene almeno un difetto, e il 56% non dichiara chiaramente il proprio scopo. Mettiamo insieme i due numeri: oltre 2.000 strumenti disponibili, più della metà dei quali non spiega bene cosa fa. Cosa succede quando il tuo agente ha 2.000 strumenti a disposizione, ma più della metà di essi non dichiara il proprio scopo? Succede che l’agente non riesce a scegliere bene, oppure spende risorse per capire da solo cosa fa ogni strumento, oppure semplicemente ignora gli strumenti peggio descritti.
Per chi pubblica strumenti e API destinate agli agenti, la lezione è netta: il contesto è il nuovo SEO. Ottimizzare la descrizione di uno strumento — renderla chiara, concisa, a basso consumo di token — non è un dettaglio tecnico. È la condizione per essere visibili, e quindi utilizzati, dagli agenti AI.
Il paper SCOUT è solo un primo segnale. Mostra che il problema è misurabile e risolvibile — 140.200 token ridotti a 1.300 in produzione presso PayPal. Ma la corsa all’efficienza del contesto è appena iniziata.
