Les développeurs utilisant des modèles de langage de grande taille (LLM) locaux découvrent qu'un seul serveur Multi-Channel-Protocol (MCP) peut consommer l'intégralité de la fenêtre de contexte avant même qu'un utilisateur ne saisisse une invite (prompt). Ils doivent choisir entre des descriptions d'outils amputées ou un flux de conversation interrompu.

Pourquoi l'inflation de jetons est cruciale pour les LLM locaux

MCP permet à un LLM d'appeler des outils externes — API, scripts ou utilitaires de système de fichiers — en fournissant au modèle une description de chaque outil. Les modèles hébergés dans le cloud avec des fenêtres de 128 k jetons peuvent absorber de nombreuses définitions d'outils tout en laissant de la place au dialogue de l'utilisateur. Un modèle de 7 milliards de paramètres fonctionnant localement avec une fenêtre de 8 k jetons manque d'espace après le chargement de seulement quelques outils. Le compromis est brutal : des descriptions courtes et économiques entraînent des erreurs d'aiguillage des appels ; des descriptions longues et détaillées consomment le budget nécessaire au chat.

La chaîne d'événements qui a mené à cette situation

MCP a été conçu pour remplacer le code d'intégration personnalisé par une interface unique, pilotée par le modèle, vers de nombreuses sources de données. La plupart des serveurs MCP agissent comme de simples wrappers autour de points de terminaison REST destinés à des opérateurs humains, et non à des machines. Lorsque ces wrappers sont intégrés à une session de LLM local, le modèle doit lire le nom, les paramètres et les notes d'utilisation de chaque outil avant de pouvoir décider lequel invoquer. Les fenêtres de contexte réduites transforment ce « surcoût de description » en un goulot d'étranglement structurel.

Qui gagne, qui perd

  • Les développeurs créant des assistants embarqués perdent en flexibilité. Ils doivent soit élaguer les catalogues d'outils, au risque de provoquer des échecs fréquents, soit accepter un prompt gonflé qui tronque l'entrée de l'utilisateur.
  • Les utilisateurs finaux constatent un comportement instable lorsque l'assistant sélectionne le mauvais outil ou refuse d'agir parce que le contexte est plein.
  • Les fournisseurs d'outils bénéficient d'un point d'entrée uniforme.

Le coût n'est pas seulement une expérience dégradée ; cela soulève des préoccupations de sécurité. Lorsqu'un agent MCP peut lire n'importe quel fichier local, le modèle de permission s'effondre en un système « tout ou rien ». Sans bac à sable (sandbox), un outil mal configuré peut exposer l'intégralité du système de fichiers.

Ce que font les développeurs pour y remédier

Trois solutions de contournement dominent la communauté :

  • Réduire les descriptions – Supprimer les métadonnées des outils pour ne garder que le strict minimum. Cela libère des jetons mais augmente le risque que le modèle choisisse le mauvais point de terminaison, entraînant des erreurs que les développeurs doivent intercepter et retenter.
  • Chargement dynamique – Charger uniquement le sous-ensemble d'outils pertinent pour la conversation en cours. Un répartiteur (dispatcher) léger décide, en fonction de l'intention de l'utilisateur, quel ensemble d'outils injecter. Cela réduit l'utilisation de jetons inutiles mais ajoute de la latence et de la complexité au code.
  • Limiter les serveurs actifs – Plafonner le nombre de serveurs MCP par session, forçant les développeurs à prioriser les intégrations les plus essentielles. Cela permet de maintenir une taille de prompt gérable, mais au détriment de l'étendue des capacités.

Aucune de ces solutions n'est une solution miracle. L'élagage des descriptions nuit à la fiabilité ; le chargement dynamique ajoute une couche de décision qui ralentit les réponses ; la limitation des serveurs impose des choix difficiles sur les sources de données à prendre en charge.

Les risques de sécurité liés au problème de jetons

Les agents locaux s'exécutent souvent avec un accès illimité au système de fichiers. Le protocole MCP n'offre aucune granularité entre « lire ce dossier » et « tout lire ». Certaines équipes ont construit des couches de passerelle (gateways) pour résoudre le problème de l'accès total, ajoutant ainsi de la complexité. Ces passerelles atténuent le problème du « contrôle total » mais augmentent également la base de code.

Concevoir des outils pour les petits modèles

Les grands modèles cloud peuvent compenser des descriptions médiocres, les développeurs négligent donc parfois la nécessité de définitions d'outils précises. Pour les modèles locaux, suivez ces principes :

  • Fonctionnalité restreinte – Chaque outil ne doit faire qu'une seule chose. Un outil de « recherche » qui écrit également des fichiers confondra un modèle incapable de gérer des responsabilités imbriquées.
  • Nomenclature sans ambiguïté – Évitez les noms génériques comme « process » ou « handle ». Les noms doivent transmettre l'opération exacte, réduisant ainsi la charge cognitive du modèle.
  • Descriptions claires et concises – N'incluez que les paramètres dont le modèle a réellement besoin pour décider. Utilisez un format cohérent afin que le modèle puisse reconnaître rapidement les schémas.

Contre-argument : le protocole conserve sa valeur

Malgré les frictions, MCP reste attractif car il fait abstraction du code répétitif (boilerplate). Une interface unique, pilotée par le modèle, peut se connecter à des dizaines de services sans avoir à écrire des adaptateurs personnalisés pour chacun. Les équipes qui ont les moyens d'utiliser des modèles à l'échelle du cloud ne voient pas l'inflation de jetons comme un problème, et la commodité l'emporte sur le surcoût. Le défi consiste à transposer cette commodité dans le monde contraint des LLM embarqués.

À retenir

Si vous construisez un assistant local, traitez les descriptions d'outils MCP comme une ressource rare. Élaguez, chargez dynamiquement et concevez des outils au périmètre restreint pour préserver la fenêtre de contexte pour la conversation réelle. En même temps, protégez-vous contre le modèle de sécurité implicite d'« accès total » en insérant une couche de permissions, même si cela coûte quelques tokens supplémentaires. L'équilibre que vous trouverez déterminera si votre LLM local ressemble à un compagnon utile ou à un chatbot défaillant.