🤖 AI

LLM within MCP Matters: Measuring Inefficient Resource Utilization Driven by LLMs

Questo studio rivela che i Large Language Models spesso ignorano i dati di riferimento inseriti in modo efficiente nelle istruzioni del server Model Context Protocol (MCP) a favore degli strumenti di ricerca a causa di preferenze comportamentali, rendendo necessari meccanismi espliciti a livello di host per dare priorità al contesto delle istruzioni rispetto alla selezione degli strumenti.

Autori originali: Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

Pubblicato 2026-08-11

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un mondo in cui il vostro assistente intelligente non si limiti a chiacchierare con voi, ma possieda anche un superpotere: la capacità di richiamare istantaneamente una vasta libreria di strumenti e database per risolvere i vostri problemi. Questa è la frontiera entusiasmante dei Large Language Models (LLM) che lavorano con gli strumenti. Pensate a un LLM come a uno studente brillante e curioso che sa molto, ma che a volte ha bisogno di fare una ricerca. Per aiutare questo studente, abbiamo un nuovo standard chiamato Model Context Protocol (MCP). Potete pensare all'MCP come a un telecomando universale che permette all' "host" dello studente (l'app che esegue lo studente) di consegnargli strumenti specifici, dati e un insieme di istruzioni su come usarli.

La grande domanda che i ricercatori si pongono è: lo studente ascolta davvero le istruzioni? A volte, le istruzioni dicono: "Ehi, ho già scritto la risposta di cui hai bisogno proprio qui su questa pagina; leggila e basta!" Ma altre volte, le istruzioni dicono anche: "Oh, e a proposito, c'è un pulsante di ricerca che puoi premere se vuoi". Si scopre che anche gli studenti più intelligenti potrebbero distrarsi con il luccicante pulsante di ricerca, ignorando la risposta che hanno proprio davanti agli occhi. Questo articolo approfondisce esattamente questo scenario per vedere se l' "abitudine alla ricerca" è più forte della capacità di leggere le istruzioni e, in caso affermativo, come possiamo risolverlo.

Il Grande Esperimento "Leggi il Menù" vs. "Chiama il Cameriere"

In questo studio, i ricercatori hanno allestito una cucina digitale chiamata Lexink, un server progettato per aiutare le persone a trovare le leggi coreane. Immaginate che questo server sia il menù di un ristorante. Di solito, se volete un piatto specifico (una legge), dovete chiedere al cameriere (lo strumento di ricerca) di andare in cucina, trovare la ricetta e portarla indietro. Questo richiede tempo e sforzo.

Tuttamente, il proprietario del ristorante (il server) ha deciso di essere intelligente. Ha stampato una lista di "Specialità del Giorno" direttamente sul tavolo (le istruzioni del server) che includeva i 20 piatti più popolari e i loro numeri d'ordine esatti. La regola era semplice: Se vuoi un piatto presente in questa lista, comunica direttamente al cameriere il numero d'ordine. Non disturbarlo chiedendogli di cercare in cucina! Questo dovrebbe essere più veloce ed economico.

I ricercatori hanno poi invitato 24 diversi studenti IA (provenienti da famiglie come Claude, Gemini e GPT) a ordinare da questo menù. Hanno condotto un esperimento massiccio con 54.000 prove per vedere cosa sarebbe successo. Gli studenti IA avrebbero letto la lista delle "Specialità del Giorno" e avrebbero ordinato direttamente? O avrebbero ignorato la lista e premuto comunque il pulsante "Cerca"?

La Scoperta Scioccante: Il Pulsante di Ricerca è Troppo Tentatore

I risultati sono stati una vera scossa. Quando i ricercatori hanno rimosso completamente il pulsante di ricerca, costringendo gli studenti a usare la lista sul tavolo, 23 modelli di IA su 24 hanno svolto un lavoro fantastico, leggendo la lista e ordinando correttamente il 98% - 100% delle volte. Questo ha dimostto che gli studenti potevano leggere le istruzioni; semplicemente non ne avevano voglia quando era disponibile un pulsante di ricerca.

Ma quando il pulsante di ricerca era presente, la storia cambiava drasticamente. 9 modelli su 24 hanno visto il proprio tasso di successo scendere sotto il 15%. Ignoravano completamente la lista delle "Specialità del Giorno" e continuavano a premere il pulsante "Cerca", anche se la risposta era lì, proprio sul tavolo. I ricercatori chiamano questo un "pregiudizio comportamentale". Non è che l'IA sia troppo stupida per leggere; è che ha l'abitudine di tendere verso lo strumento che conosce meglio, anche quando è la scelta meno efficiente. È come un bambino che sa che la risposta è a pagina 5, ma continua a chiedere all'insegnante di aprire il libro a pagina 5.

Interessante notare che essere "più nuovi" o "più intelligenti" non garantiva un comportamento migliore. Alcuni dei modelli più recenti sono stati in realtà peggiori nel seguire questa specifica regola rispetto ai loro fratelli maggiori. Lo studio ha scoperto che la recenza del modello non predice chi sarà un buon ascoltatore in questa situazione.

Possiamo Addestrarli ad Ascoltare? (La Formula Magica)

I ricercatori hanno poi cercato di correggere questa cattiva abitudine cambiando le istruzioni sul tavolo. Hanno testato tre diversi trucchi:

L'Intestazione Autoritaria (B): Un avviso grande e grassetto che dice: "DEVI usare la lista! NON cercare!"
L'Esempio (C): Mostrare l'immagine di qualcuno che lo fa correttamente e di qualcuno che lo fa in modo errato.
L'Indizio (D): Cambiare la descrizione del pulsante di ricerca dicendo: "Controlla prima la lista prima di usarmi."

Hanno combinato questi trucchi in ogni possibile combinazione. I risultati hanno mostrato che nessun trucco da solo funzionava per tutti. Infatti, per alcuni modelli di IA, l'uso del solo "Intestazione Autoritaria" li ha fatti performare peggio (scendendo allo 0% in un caso!). È come come un grido forte possa spaventare uno studente portandolo a lavorare, ma far paralizzare un altro.

Tuttavia, quando hanno combinato tutti e tre i trucchi insieme, i risultati sono stati incredibili. 20 modelli su 24 sono tornati a un tasso di successo dell'86% o superiore. Ciò suggerisce che, sebbene non si possa semplicemente urlare a un'IA per correggere le sue abitudini, un approccio ben strutturato che combina avvisi, esempi e indizi può riportare la maggior parte di loro sulla retta via.

Cosa Significa per il Futuro

Il punto principale è che non basta dare a un'IA uno strumento e un insieme di istruzioni. L'IA potrebbe avere un "riflesso di ricerca" che sovrasta le istruzioni, portando a spreco di tempo e risorse. Il documento sostiene che le applicazioni che eseguono queste IA (gli "host") devono intervenire. Invece di sperare che l'IA legga le istruzioni, l'app dovrebbe forzare l'IA a controllare le istruzioni prima ancora che le sia permesso di scegliere uno strumento.

Finché ciò non accadrà, gli sviluppatori dovranno essere prudenti. Non possono limitarsi a scrivere un set di istruzioni e aspettarsi che funzioni per ogni IA. Devono testare le loro istruzioni contro i modelli "più deboli" che prevedono di utilizzare, e dovrebbero usare un mix di esempi e indizi piuttosto che semplici comandi autoritari. Lo studio dimostra che, sebbene il problema sia reale, è anche risolvibile con la giusta ricetta di istruzioni.

Riepilogo Tecnico: LLM all'interno di MCP Matters: Misurare l'inefficiente utilizzo delle risorse guidato dagli LLM

Problema

Lo standard Model Context Protocol (MCP) standardizza il modo in cui i server espongono dati e strumenti ai Large Language Models (LLM). Un modello di progettazione diffuso prevede l'inserimento di dati di riferimento utilizzati frequentemente (ad esempio, tabelle di lookup degli identificatori) direttamente nelle Istruzioni del Server (il testo del system-prompt fornito al client LLM). Teoricamente, ciò consente al modello di bypassare le chiamate agli strumenti (come la ricerca) per le voci note, riducendo l'uso di token e la latenza.

Tuttavia, l'efficacia di questo schema rimane non verificata su larga scala. Sebbene i server forniscano queste istruzioni, il client LLM deve scegliere di seguirle rispetto agli schemi degli strumenti disponibili. Prove precedenti suggeriscono una bassa conformità alle istruzioni del server e fallimenti nelle gerarchie di istruzioni. Questo articolo investiga se i client LLM consumino effettivamente i dati inseriti nelle istruzioni o se esibiscano una preferenza comportamentale per l'invocazione di strumenti di ricerca anche quando i dati necessari sono esplicitamente forniti nel contesto.

Metodologia

Gli autori hanno condotto uno studio empirico su larga scala utilizzando LexLink, un server MCP di produzione per il recupero di informazioni legali coreane.

Testbed: Il server espone 26 strumenti. Per le 20 leggi più richieste, le istruzioni del server incorporano una tabella che mappa i nomi delle leggi agli ID. Un client efficiente dovrebbe utilizzare eflaw_service con l'ID memorizzato direttamente, invece di chiamare eflaw_search per risolvere l'ID in primo luogo.
Modelli Valutati: 24 LLM appartenenti a tre provider (9 Anthropic Claude, 6 Google Gemini, 9 OpenAI GPT), che spaziano tra diverse generazioni e livelli di capacità.
Scala: 54.000 prove (24 modelli × 9 condizioni × 5 query × 50 round).
Metrica: Hit Ratio ( $\phi$ ): La frazione di prove in cui la prima chiamata allo strumento del modello è la corretta eflaw_service con l'ID memorizzato. Qualsiasi altra prima chiamata (inclusa la ricerca o l'ID errato) è un errore (miss).
Condizioni Sperimentali:
- Baseline: Istruzioni standard del server con la tabella incorporata e lo strumento di ricerca disponibile.
- Diagnostica (no_s): Lo strumento di ricerca viene rimosso completamente. Ciò isola la capacità (il modello sa leggere la tabella?) dalla preferenza (sceglie la tabella rispetto allo strumento?).
- Interventi Fattoriali ( $2^3$ ): Tre modifiche a livello di istruzione sono state testate singolarmente e in combinazione:
  - B (Direttiva): Un header "CRITICAL" che impone l'uso diretto degli ID memorizzati.
  - C (Few-shot): Esempi che mettono a confronto pattern corretti e errati.
  - D (Suggerimento Strumento): Modifica della descrizione dello strumento di ricerca per avvisare gli utenti di controllare prima la tabella delle istruzioni.

Risultati Chiave

Capacità vs Preferenza:
- Sotto la condizione no_s (strumento di ricerca rimosso), 23 di 24 modelli hanno ottenuto un hit ratio $\ge$ 98%, provando che possiedono la capacità di leggere e utilizzare i dati inseriti nelle istruzioni.
- Sotto la condizione baseline (strumento di ricerca presente), 9 modelli sono scesi sotto il 15%.
- Conclusione: Il fallimento è guidato da una preferenza comportamentale per l'invocazione dello strumento di ricerca piuttosto che da una mancanza di capacità di interpretare le istruzioni. La mera presenza di uno strumento di ricerca sovrasta i dati incorporati per molti modelli.
Performance Non-Monotoniche:
- L'efficienza non correla con la recenza o la generazione del modello. Sono state osservate regressioni degne di nota:
  - GPT-4.1 (99%) $\to$ GPT-5 (1%).
  - Gemini 2.5-pro (100%) $\to$ Gemini 3-pro (2%).
  - Claude Opus 4.5 (100%) $\to$ Opus 4.6 (63%).
- Ciò suggerisce che il post-training su benchmark agentici possa involontariamente rinforzare le policy di tool-calling che ignorano i dati del contesto.
Analisi degli Interventi Fattoriali:
- Gli interventi individuali (B, C o D) hanno mostrato un'alta varianza e potevano rivelarsi controproducenti. Ad esempio, applicare solo la Direttiva (B) ha causato il calo delle performance di GPT-5.2 dal 5% allo 0%.
- Effetti di Interazione: Esistono forti interazioni tra i fattori. La combinazione di tutti e tre (BCD) ha ripristinato le performance $\ge$ 86% per 20 di 24 modelli.
- I design a fattore singolo avrebbero mancato queste interazioni critiche e il potenziale degli interventi di degradare le performance.

Significato e Rivendicazioni

L'articolo sostiene che l'ingegneria del prompt per singolo server sia un workaround piuttosto che una soluzione definitiva. Poiché i singoli interventi possono fallire o invertirsi a seconda della famiglia di modelli, fare affidamento esclusivamente sul fine-tuning delle istruzioni è fragile.

Gli autori propongono tre implicazioni:

Valutazione Congiunta delle Capacità: Le capacità del server MCP non possono essere valutate in isolamento; dipendono fortemente dal comportamento del client LLM.
Meccanismi lato Host: Le applicazioni host MCP (ad esempio, Claude Desktop, Cursor) dovrebbero fornire meccanismi espliciti per dare priorità alle istruzioni del server nel processo di deliberazione del client LLM (ad esempio, iniettando le istruzioni come direttive a priorità di sistema o imponendo un controllo "consulta-le-istruzioni-per-primo" prima della selezione dello strumento).
Guida per gli Sviluppatori di Server: Gli sviluppatori dovrebbero includere esempi few-shot (che hanno mostrato effetti positivi o trascurabili su tutti i modelli) e combinare più tipi di intervento (B, C e D) per una copertura più ampia, validando al contempo rispetto ai modelli client più deboli previsti.

Lo studio è limitato a un singolo dominio di server (ricerca legale) e interazioni a turno singolo. Sebbene sia in corso uno studio ampliato su quattro server MCP aggiuntivi (geografico, accademico, database, messaggistica), gli autori dichiarano esplicitamente che i risultati preliminari sono citati come una prospettiva piuttosto che come prova dei risultati qui riportati.