🤖 AI

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

Deze studie onthult dat Large Language Models vaak efficiënt ingebedde referentiedata in Model Context Protocol (MCP) serverinstructies negeren ten gunste van zoektools vanwege gedragspreferenties, wat expliciete mechanismen op host-niveau noodzakelijk maakt om de instructiecontext te prioriteren boven de toolselectie.

Oorspronkelijke auteurs: Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

Gepubliceerd 2026-08-11

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een wereld voor waarin je slimme assistent niet alleen met je chat, maar ook een superkracht heeft: het kan direct een enorme bibliotheek aan tools en databases oproepen om je problemen op te lossen. Dit is de opwindende grens van Large Language Models (LLMs) die werken met tools. Zie een LLM als een briljante, nieuwsgierige student die veel weet, maar soms even moet opzoeken. Om deze student te helpen, hebben we een nieuwe standaard: het Model Context Protocol (MCP). Je kunt MCP zien als een universele afstandsbediening waarmee de "host" (de app waarin de student draait) specifieke tools, data en een set instructies over hoe ze te gebruiken, kan overhandigen.

De grote vraag die onderzoekers stellen is: Luistert de student eigenlijk wel naar de instructies? Soms zeggen de instructies: "Hé, ik heb het antwoord dat je nodig hebt al hier op deze pagina geschreven; lees het gewoon!" Maar andere keren zeggen de instructies ook: "Oh, en trouwens, er is een zoekknop die je kunt indrukken als je wilt." Het blijkt dat zelfs de slimste studenten afgeleid kunnen raken door die glimmende zoekknop, waardoor ze de instructies negeren terwijl het antwoord recht voor hun neus ligt. Dit artikel duikt precies in dat scenario om te zien of de "zoekverslaving" sterker is dan het vermogen om instructies op te volgen, en zo ja, hoe we dat kunnen oplossen.

Het Grote "Lees de Menukaart" vs. "Roep de Ober" Experiment

In deze studie zetten de onderzoekers een digitale keuken op genaamd LexLink, een server die mensen helpt bij het vinden van Koreaanse wetten. Stel je voor dat deze server een restaurantmenu is. Normaal gesproken, als je een specifere gerecht (een wet) wilt, moet je de ober (de zoektool) vragen om naar de keuken te gaan, het recept te zoeken en het terug te brengen. Dit kost tijd en moeite.

De restauranthouder (de server) besloot echter slim te zijn. Ze drukten een "Dagspecialen"-lijst direct op de tafel (de serverinstructies) die de top 20 meest populaire gerechten inclusief hun exacte bestelnummers bevatte. De regel was simpel: Als je een gerecht op deze lijst wilt, noem dan direct het bestelnummer aan de ober. Maak de moeite niet om hem de keuken in te laten zoeken! Dit zou sneller en goedkoper moeten zijn.

De onderzoekers nodigden vervolgens 24 verschillende AI-studenten uit (uit families zoals Claude, Gemini en GPT) om van deze menukaart te bestellen. Ze voerden een massaal experiment uit met 54.000 proeven om te zien wat er zou gebeuren. Zouden de AI-studenten de "Dagspecialen"-lijst lezen en direct bestellen? Of zouden ze de lijst negeren en toch op de "Zoek"-knop drukken?

De Schokkende Ontdekking: De Zoekknop is Te Verleidelijk

De resultaten waren een beetje een waarschuwing. Wanneer de onderzoekers de zoekknop volledig verwijderden, waardoor de studenten gedwongen werden de lijst op tafel te gebruiken, deed 23 van de 24 AI-modellen het fantastisch: ze lazen de lijst en bestelden correct in 98% tot 100% van de gevallen. Dit bewees dat de studenten de instructies konden lezen; ze wilden het alleen niet als er een zoekknop aanwezig was.

Maar wanneer de zoekknop aanwezig was, veranderde het verhaal drastisch. 9 van de 24 modellen zagen hun succespercentage dalen tot onder de 15%. Ze negeerden de "Dagspecialen"-lijst volledig en bleven op de zoekknop drukken, ook al lag het antwoord gewoon op tafel. De onderzoekers noemen dit een "behavioral preference" (gedragsvoorkeur). Het is niet dat de AI te dom is om te lezen; het is dat de AI een gewoonte heeft om naar de tool te grijpen die het het beste kent, zelfs als dat de inefficiënte keuze is. Het is als een kind dat weet dat het antwoord op pagina 5 staat, maar de leraar toch steeds blijft vragen om het boek op pagina 5 te openen.

Interessant genoeg garandeerde het feit dat een model "nieuwer" of "slimmer" was, geen beter gedrag. Sommige van de allernieuwste modellen vertoonden zelfs slechter gedrag bij het volgen van deze specifieke regel dan hun oudere broertjes en zusjes. De studie vond dat de recentheid van een model niet voorspelt wie een goede luisteraar zal zijn in deze situatie.

Kunnen We Ze Trainen om te Luisteren? (De Magische Formule)

De onderzoekers probeerden dit slechte gedrag vervolgens te corrigeren door de instructies op de tafel te veranderen. Ze testten drie verschillende trucjes:

De Baasachtige Kop (B): Een grote, vette waarschuwing: "MOET de lijst gebruiken! NIET zoeken!"
Het Voorbeeld (C): Een afbeelding tonen van iemand die het goed doet en iemand die het fout doet.
De Hint (D): De beschrijving van de zoekknop veranderen naar: "Controleer eerst de lijst voordat je mij gebruikt."

Ze combineerden deze trucjes in elke mogelijke variatie. De resultaten lieten zien dat geen enkele truc voor iedereen werkte. Sterker nog, bij sommige AI-modellen zorgde het gebruik van enkel de "Baasachtige Kop" ervoor dat ze juist slechter presteerden (met een daling naar 0% in één geval!). Het is net zoals hoe een harde schreeuw de ene student kan laten werken, maar een andere student kan doen bevriezen.

Echter, wanneer ze alle drie de trucjes samen gebruikten, waren de resultaten verbazingwekkend. 20 van de 24 modellen sprongen terug naar een succespercentage van 86% of hoger. Dit suggereert dat je een AI niet simpelweg kunt uitschelden om een gewoonte te corrigeren, maar dat een weloverwogen aanpak die waarschuwingen, voorbeelden en hints combineert, de meeste van hen weer op het juiste pad krijgt.

Wat Dit Betekent voor de Toekomst

De belangrijkste les is dat het simpelweg geven van een tool en een set instructies aan een AI niet genoeg is. De AI kan een "zoekreflex" hebben die de instructies overschrijft, wat leidt tot verspilling van tijd en middelen. Het artikel betoogt dat de apps die deze AI's draaien (de "hosts") moeten ingrijpen. In plaats van te hopen dat de AI de instructies leest, moet de app de AI dwingen om de instructies te controleren voordat het überhaupt een tool mag kiezen.

Totdat dat gebeurt, moeten ontwikkelaars voorzichtig zijn. Ze kunnen niet zomaar één set instructies schrijven en verwachten dat het voor elke AI werkt. Ze moeten hun instructies testen tegen de "zwakste" modellen die ze verwachten te gebruiken, en ze moeten een mix van voorbeelden en hints gebruiken in plaats van alleen maar baasachtige commando's. De studie laat zien dat hoewel het probleem reëel is, het ook oplosbaar is met het juiste recept van instructies.

Technische Samenvatting: LLM binnen MCP Matters: Meten van inefficiënt hulpbrongebruik gedreven door LLM's

Probleemstelling

De Model Context Protocol (MCP) standaardiseert de manier waarop servers gegevens en tools exposeren aan Large Language Models (LLM's). Een veelvoorkomend ontwerppatroon is het inbedden van veelgebruikte referentiedata (bijv. identificatie-zoektabellen) direct in de Server Instructies—de systeem-prompt tekst die aan de client-LLM wordt verstrekt. Theoretisch stelt dit het model in staat om tool calls (zoals zoeken) te omzeilen voor bekende vermeldingen, wat het tokenverbruik en de latentie vermindert.

De effectiviteit van dit patroon blijft echter onverifieerd op schaal. Hoewel servers deze instructies verstrekken, moet de client-LLM ervoor kiezen om ze te volgen boven de beschikbare tool-schema's. Er is eerder bewijs gevonden voor een lage naleving van serverinstructies en falen in instructiehiërarchieën. Dit paper onderzoekt of client-LLM's daadwerkelijk de in instructies ingebedde data consumeren, of dat zij een gedragspreferentie vertonen om zoektools aan te roepen, zelfs wanneer de benodigde data expliciet in de context aanwezig is.

Methodologie

De auteurs voerden een grootschalige empirische studie uit met behulp van LexLink, een productie-MCP-server voor Koreaanse juridische informatie-extractie.

Testbed: De server exposeert 26 tools. Voor de 20 meest gevraagde wetten bedt de serverinstructie een tabel die wetnamen aan ID's koppelt. Een efficiënte client zou eflaw_service moeten gebruiken met de gecachte ID, in plaats van eerst eflaw_search aan te roepen om de ID op te zoeken.
Geëvalueerde modellen: 24 LLM's van drie providers (9 Anthropic Claude, 6 Google Gemini, 9 OpenAI GPT), variërend over meerdere generaties en capaciteitsniveaus.
Schaal: 54.000 trials (24 modellen × 9 condities × 5 queries × 50 rondes).
Metriek: Hit Ratio ( $\phi$ ): Het deel van de trials waarbij de eerste tool call van het model de correcte eflaw_service is met de gecachte ID. Elke andere eerste call (inclusief zoeken of een foutieve ID) is een miss.
Experimentele condities:
- Baseline: Standaard serverinstructies met de ingebedde tabel en de zoektool beschikbaar.
- Diagnostisch (no_s): De zoektool is volledig verwijderd. Dit isoleert capaciteit (kan het model de tabel lezen?) van preferentie (kiest het model de tabel boven de tool?).
- Factoriële interventies ( $2^3$ ): Drie instructieniveau-modificaties werden individueel en in combinatie getest:
  - B (Directieve): Een "CRITICAL" header die direct gebruik van gecachte ID's verplicht.
  - C (Few-shot): Voorbeelden die correcte versus incorrecte tool-patronen contrasteren.
  - D (Tool Hint): De beschrijving van de zoektool wijzigen om gebruikers te waarschuwen eerst de instructietabel te controleren.

Belangrijkste Resultaten

Capaciteit vs. Preferentie:
- Onder de no_s conditie (zoektool verwijderd), behaalden 23 van de 24 modellen een hit ratio $\ge$ 98%, wat bewijst dat zij de capaciteit bezitten om instructie-ingebedde data te lezen en te gebruiken.
- Onder de baseline conditie (zoektool aanwezig), daalden 9 modellen onder de 15%.
- Conclusie: Het falen wordt gedreven door een gedragspreferentie om de zoektool aan te roepen, in plaats van een gebrek aan de capaciteit om instructies te parsen. De loutere aanwezigheid van een zoektool overrulet de ingebedde data voor veel modellen.
Niet-monotone Prestaties:
- Efficiëntie correleert niet met de recentheid of generatie van het model. Opmerkelijke regressies werden waargenomen:
  - 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%).
- Dit suggereert dat post-training op agentische benchmarks onbedoeld tool-calling policies kan versterken die contextuele data negeren.
Factoriële Interventie Analyse:
- Individuele interventies (B, C of D) vertoonden een hoge variantie en konden averechts werken. Zo zorgde het toepassen van enkel de Directieve (B) ervoor dat de prestaties van GPT-5.2 daalden van 5% naar 0%.
- Interactie-effecten: Sterke interacties bestaan tussen factoren. De combinatie van alle drie (BCD) herstelde de prestaties naar $\ge$ 86% voor 20 van de 24 modellen.
- Ontwerpen met één factor zouden deze kritieke interacties en het potentieel van interventies om prestaties te verslechteren gemist hebben.

Betekenis en Claims

Het paper betoogt dat per-server prompt engineering een workaround is in plaats van een oplossing. Omdat individuele interventies kunnen falen of omkeren afhankelijk van de modelfamilie, is het vertrouwen op enkel instructie-tuning broos.

De auteurs stellen drie implicaties voor:

Gezamenlijke Capaciteitsbeoordeling: De capaciteiten van een MCP-server kunnen niet in isolatie worden geëvalueerd; ze zijn sterk afhankelijk van het gedrag van de client-LLM.
Mechanismen aan de Host-zijde: MCP-hostapplicaties (bijv. Claude Desktop, Cursor) moeten expliciete mechanismen bieden om de prioriteit van serverinstructies in het deliberatieproces van de client-LLM te verhogen (bijv. door instructies als systeem-prioritaire directieven voor te injecteren of een "raad-eerst-instructies-in" controle af te dwingen vóór tool selectie).
Richtlijnen voor Serverontwikkelaars: Ontwikkelaars moeten few-shot voorbeelden opnemen (die een positief of verwaarloosbaar effect lieten zien over alle modellen) en meerdere interventietypes combineren (B, C en D) voor bredere dekking, terwijl ze valideren tegen de zwakste verwachte client-modellen.

De studie is beperkt tot één serverdomein (juridische lookup) en single-turn interacties. Hoewel een uitgebreide studie op vier aanvullende MCP-servers (geografisch, academisch, database, messaging) in gang is gezet, verklaren de auteurs expliciet dat de voorlopige resultaten daarvan als een vooruitblik worden aangehaald en niet als bewijs voor de hier gerapporteerde bevindingen.