🤖 AI

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

Cette étude révèle que les grands modèles de langage ignorent souvent les données de référence intégrées efficacement dans les instructions des serveurs du protocole MCP (Model Context Protocol) au profit d'outils de recherche en raison de préférences comportementales, ce qui nécessite des mécanismes explicites au niveau de l'hôte pour donner la priorité au contexte des instructions sur la sélection d'outils.

Auteurs originaux : Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

Publié 2026-08-11

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez un monde où votre assistant intelligent ne se contente pas de discuter avec vous, mais possède également un super-pouvoir : il peut faire appel instantanément à une vaste bibliothèque d'outils et de bases de données pour résoudre vos problèmes. C'est la frontière passionnante des Modèles de Langage Étendus (LLM) travaillant avec des outils. Considérez un LLM comme un étudiant brillant et curieux qui en sait beaucoup, mais qui a parfois besoin de faire des recherches. Pour aider cet étudiant, nous avons un nouveau standard appelé le Model Context Protocol (MCP). Vous pouvez voir le MCP comme une télécommande universelle qui permet à l'« hôte » de l'étudiant (l'application qui fait tourner l'étudiant) de lui remettre des outils spécifiques, des données et un ensemble d'instructions sur la façon de les utiliser.

La grande question que se posent les chercheurs est la suivante : L'étudiant écoute-t-il réellement les instructions ? Parfois, les instructions disent : « Hé, j'ai déjà écrit la réponse dont vous avez besoin juste ici sur cette page ; lisez-la simplement ! ». Mais d'autres fois, les instructions disent aussi : « Oh, et au fait, il y a un bouton de recherche que vous pouvez presser si vous le souhaitez ». Il s'avère que même les étudiants les plus brillants peuvent être distraits par le bouton de recherche brillant, ignorant la réponse située juste devant eux. Cette publication plonge précisément dans ce scénario pour voir si l'« habitude de recherche » est plus forte que la capacité à lire les instructions, et si, dans ce cas, nous pouvons la corriger.

La grande expérience du « Lire le menu » contre « Appeler le serveur »

Dans cette étude, les chercheurs ont mis en place une cuisine numérique appelée LexLink, un serveur conçu pour aider les gens à trouver des lois coréennes. Imaginez que ce serveur soit un menu de restaurant. Habituellement, si vous voulez un plat spécifique (une loi), vous devez demander au serveur d'aller à la cuisine, de trouver la recette et de vous l'apporter. Cela prend du temps et des efforts.

Cependant, le propriétaire du restaurant (le serveur) a décidé d'être intelligent. Ils ont imprimé une liste des « Spécialités du jour » directement sur la table (les instructions du serveur) qui incluait les 20 plats les plus populaires et leur numéro de commande exact. La règle était simple : Si vous voulez un plat de cette liste, donnez directement le numéro de commande au serveur. Ne vous donnez pas la peine de lui demander de chercher dans la cuisine ! C'est censé être plus rapide et moins coûteux.

Les chercheurs ont ensuite invité 24 étudiants IA différents (issus de familles comme Claude, Gemini et GPT) à commander sur ce menu. Ils ont mené une expérience massive de 54 000 essais pour voir ce qui se passerait. Les étudiants IA liraient-ils la liste des « Spécialités du jour » et commanderaient directement ? Ou ignoreraient-ils la liste pour appuyer sur le bouton « Rechercher » malgré tout ?

La découverte choc : Le bouton de recherche est trop tentant

Les résultats ont été un véritable rappel à la réalité. Lorsque les chercheurs ont complètement supprimé le bouton de recherche, forçant les étudiants à utiliser la liste sur la table, 23 des 24 modèles d'IA ont fait un travail fantastique, lisant la liste et commandant correctement 98 % à 100 % du temps. Cela a prouvé que les étudiants pouvaient lire les instructions ; ils ne le voulaient simplement pas lorsqu'un bouton de recherche était disponible.

Mais quand le bouton de recherche était présent, l'histoire changeait radicalement. 9 des 24 modèles ont vu leur taux de réussite chuter en dessous de 15 %. Ils ignoraient complètement la liste des « Spécialités du jour » et continuaient d'appuyer sur le bouton de recherche, même si la réponse était juste là, sous leurs yeux. Les chercheurs appellent cela une « préférence comportementale ». Ce n'est pas que l'IA est trop stupide pour lire ; c'est qu'elle a l'habitude de saisir l'outil qu'elle connaît le mieux, même lorsqu'il s'agit du choix le moins efficace. C'est comme un enfant qui sait que la réponse est à la page 5, mais qui continue de demander au professeur d'ouvrir le livre à la page 5 quand même.

Il est intéressant de noter que le fait d'être plus « récent » ou plus « intelligent » ne garantissait pas un meilleur comportement. Certains des modèles les plus récents étaient en fait moins bons pour suivre cette règle spécifique que leurs aînés. L'étude a révélé que la récence du modèle ne prédit pas qui sera un bon auditeur dans cette situation.

Pouvons-nous les entraîner à écouter ? (La formule magique)

Les chercheurs ont ensuite tenté de corriger cette mauvaise habitude en modifiant les instructions sur la table. Ils ont testé trois astuces différentes :

L'en-tête autoritaire (B) : Un avertissement large et gras disant : « VOUS DEVEZ utiliser la liste ! NE PAS rechercher ! »
L'exemple (C) : Montrer une image de quelqu'un faisant correctement et de quelqu'un faisant mal.
L'indice (D) : Changer la description du bouton de recherche pour dire : « Consultez la liste avant de m'utiliser. »

Ils ont mélangé et combiné ces astuces dans toutes les combinações possibles. Les résultats ont montré qu'aucune astuce ne fonctionnait pour tout le monde. En fait, pour certains modèles d'IA, l'utilisation du seul « En-tête autoritaire » les faisait performer pire (tombant à 0 % dans un cas !). C'est comme si un cri fort pouvait effrayer un élève et le faire travailler, mais faire figurer un autre dans l'immobilisme.

Cependant, lorsqu'ils ont combiné les trois astuces ensemble, les résultats ont été incroyables. 20 des 24 modèles sont remontés à des taux de réussite de 86 % ou plus. Cela suggère que, bien que vous ne puissiez pas simplement crier sur une IA pour corriger ses habitudes, une approche bien équilibrée combinant avertissements, exemples et indices peut ramener la plupart d'entre elles sur le bon chemin.

Ce que cela signifie pour l'avenir

La principale conclusion est que donner simplement un outil et un ensemble d'instructions à une IA ne suffit pas. L'IA peut avoir un « réflexe de recherche » qui supplante les instructions, entraînant une perte de temps et de ressources. L'article soutient que les applications qui font tourner ces IA (les « hôtes ») doivent intervenir. Au lieu d'espérer que l'IA lise les instructions, l'application devrait forcer l'IA à vérifier les instructions avant même qu'elle ne soit autorisée à choisir un outil.

En attendant que cela arrive, les développeurs doivent être prudents. Ils ne peuvent pas se contenter d'écrire un ensemble d'instructions et s'attendre à ce que cela fonctionne pour chaque IA. Ils doivent tester leurs instructions contre les modèles les plus « faibles » qu'ils prévoient d'utiliser, et ils devraient utiliser un mélange d'exemples et d'indices plutôt que de simples ordres autoritaires. L'étude montre que bien que le problème soit réel, il est aussi soluble avec la bonne recette d'instructions.

Résumé technique : L'impact des LLM au sein du MCP : Mesurer l'utilisation inefficace des ressources induite par les LLM

Énoncé du problème

Le standard Model Context Protocol (MCP) normalise la manière dont les serveurs exposent des données et des outils aux modèles de langage de grande taille (LLM). Un motif de conception prévalent consiste à intégrer des données de référence fréquemment utilisées (par exemple, des tables de correspondance d'identifiants) directement dans les Instructions du Serveur — le texte du prompt système fourni au client LLM. Théoriquement, cela permet au modèle de contourner les appels d'outils (tels que la recherche) pour les entrées connues, réduisant ainsi l'utilisation de tokens et la latence.

Cependant, l'efficacité de ce motif reste non vérifiée à grande échelle. Bien que les serveurs fournissent ces instructions, le client LLM doit choisir de les suivre plutôt que d'utiliser les schémas d'outils disponibles. Des preuves antérieures suggèrent une faible conformité aux instructions du serveur et des échecs dans les hiérarchies d'instructions. Cette étude examine si les clients LLM consomment réellement les données intégrées aux instructions ou s'ils présentent une préférence comportementale pour l'invocation d'outils de recherche, même lorsque les données nécessaires sont explicitement fournies dans le contexte.

Méthodologie

Les auteurs ont mené une étude empirique à grande échelle en utilisant LexLink, un serveur MCP de production pour la recherche d'informations juridiques coréennes.

Banc d'essai : Le serveur expose 26 outils. Pour les 20 lois les plus fréquemment demandées, les instructions du serveur intègrent une table faisant correspondre les noms de lois aux identifiants (IDs). Un client efficace devrait utiliser eflaw_service avec l'ID mis en cache directement, plutôt que d'appeler eflaw_search pour résoudre l'ID au préalable.
Modèles évalués : 24 LLM provenant de trois fournisseurs (9 Anthropic Claude, 6 Google Gemini, 9 OpenAI GPT), couvrant plusieurs générations et niveaux de capacité.
Échelle : 54 000 essais (24 modèles × 9 conditions × 5 requêtes × 50 tours).
Métrique : Taux de succès ( $\phi$ ) : La fraction des essais où le premier appel d'outil du modèle est le bon eflaw_service avec l'ID mis en cache. Tout autre premier appel (incluant la recherche ou un mauvais ID) est considéré comme un échec.
Conditions expérimentales :
- Baseline (Référence) : Instructions de serveur standard avec la table intégrée et l'outil de recherche disponible.
- Diagnostic (no_s) : L'outil de recherche est totalement supprimé. Cela permet d'isoler la capacité (le modèle peut-il lire la table ?) de la préférence (choisit-il la table plutôt que l'outil ?).
- Interventions factorielles ( $2^3$ ) : Trois modifications au niveau des instructions ont été testées individuellement et en combinaison :
  - B (Directive) : Un en-tête "CRITICAL" imposant l'utilisation directe des IDs mis en cache.
  - C (Few-shot) : Des exemples contrastant les modèles corrects et incorrects.
  - D (Indice d'outil) : Modification de la description de l'outil de recherche pour avertir les utilisateurs de vérifier d'abord la table d'instructions.

Résultats clés

Capacité vs Préférence :
- Sous la condition no_s (outil de recherche supprimé), 23 des 24 modèles ont atteint un taux de succès $\ge$ 98 %, prouvant qu'ils possèdent la capacité de lire et d'utiliser les données intégrées aux instructions.
- Sous la condition de base (outil de recherche présent), 9 modèles sont tombés en dessous de 15 %.
- Conclusion : L'échec est dû à une préférence comportementale pour l'invocation de l'outil de recherche plutôt qu'à un manque de capacité à analyser les instructions. La simple présence d'un outil de recherche supplante les données intégrées pour de nombreux modèles.
Performance non monotone :
- L'efficacité ne corrèle pas avec la récence ou la génération du modèle. Des régressions notables ont été observées :
  - 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 %).
- Cela suggère que le post-entraînement sur des benchmarks agentiques peut involontairement renforcer des politiques d'appel d'outils qui ignorent les données de contexte.
Analyse des interventions factorielles :
- Les interventions individuelles (B, C ou D) ont montré une grande variance et pouvaient être contre-productives. Par exemple, l'application de la seule Directive (B) a fait chuter la performance de GPT-5.2 de 5 % à 0 %.
- Effets d'interaction : Des interactions fortes existent entre les facteurs. La combinaison des trois (BCD) a restauré la performance à $\ge$ 86 % pour 20 des 24 modèles.
- Les conceptions à facteur unique auraient manqué ces interactions critiques et le potentiel de dégradation des performances par les interventions.

Signification et revendications

L'article soutient que l'ingénierie de prompt par serveur est un contournement plutôt qu'une solution. Comme les interventions individuelles peuvent échouer ou s'inverser selon la famille de modèles, compter uniquement sur l'ajustement des instructions est fragile.

Les auteurs proposent trois implications :

Évaluation conjointe des capacités : Les capacités d'un serveur MCP ne peuvent être évaluées de manière isolée ; elles dépendent fortement du comportement du client LLM.
Mécanismes côté hôte : Les applications hôtes MCP (ex: Claude Desktop, Cursor) devraient fournir des mécanismes explicites pour prioriser les instructions du serveur dans le processus de délibération du client LLM (ex: pré-injection des instructions comme directives prioritaires du système ou application d'une vérification "consulter les instructions d'abord" avant la sélection de l'outil).
Conseils aux développeurs de serveurs : Les développeurs devraient inclure des exemples de few-shot (qui ont montré des effets positifs ou négligeables sur tous les modèles) et combiner plusieurs types d'interventions (B, C et D) pour une couverture plus large, tout en validant par rapport aux modèles clients les plus faibles attendus.

L'étude est limitée à un seul domaine de serveur (recherche juridique) et à des interactions en un seul tour. Bien qu'une étude étendue sur quatre serveurs MCP supplémentaires (géographique, académique, base de données, messagerie) soit en cours, les auteurs déclarent explicitement que ses résultats préliminaires sont cités comme une perspective et non comme une preuve des conclusions rapportées ici.