Pi réduit l'encombrement des jetons MCP en masquant les outils derrière un bac à sable Codemode

Pi, l'agent de codage créé par Mario Zechner, a finalement intégré le Model Context Protocol (MCP) dans son architecture centrale après avoir passé une grande partie de l'année précédente à l'exclure. Ce changement intervient avec Pi 1.0, suite au rachat par Earendil plus tôt cette année, et introduit une méthode novatrice pour gérer les lourds coûts de contexte associés aux implémentations MCP standard.

L'intégration ne suit pas l'approche traditionnelle consistant à exposer tous les outils du serveur directement au grand modèle de langage. Au lieu de cela, Pi utilise un mécanisme interne appelé Codemode pour médier l'accès, garantissant que les définitions d'outils restent cachées jusqu'à ce qu'elles soient explicitement requises pour une tâche spécifique.

Ce qui s'est passé

Pendant la majeure partie de l'année dernière, Zechner a résisté à l'ajout du support MCP à Pi malgré la normalisation du protocole dans les outils de développement. Son hésitation provenait de métriques de performance concrètes. Lorsqu'il a mesuré les serveurs populaires d'automatisation de navigateur, il a constaté que la connexion de Chrome DevTools via MCP consommait environ 18 000 jetons. Cette utilisation représentait environ 9 % d'une fenêtre de contexte de 200 000 jetons avant que l'agent n'ait effectué un quelconque travail utile.

D'autres outils présentaient des charges similaires. Playwright MCP nécessitait environ 13 700 jetons pour décrire ses 21 outils, consommant 6,8 % de la même fenêtre de contexte. Chaque serveur supplémentaire ajoutait plus de surcharge, réduisant l'espace disponible pour le code réel et le raisonnement. Zechner a également critiqué le manque de composabilité dans les configurations MCP standard, notant que les résultats renvoyés par un serveur doivent passer par le contexte de l'agent pour être persistés ou combinés avec d'autres données.

Durant cette période, Pi comptait sur des scripts Bash et des interfaces en ligne de commande pour l'automatisation du navigateur. Ces outils ne nécessitaient qu'un README de 225 jetons car le modèle comprenait déjà comment les utiliser. Les sorties pouvaient être redirigées, filtrées ou enregistrées sur disque sans encombrer la fenêtre de contexte du modèle. Des extensions communautaires comme pi-mcp-adapter permettaient aux utilisateurs de faire le pont entre MCP et Pi, mais le support natif restait absent.

Earendil, qui a racheté Pi plus tôt cette année, a décidé de reconsidérer MCP. L'entreprise a déclaré que le protocole avait mûri et que les changements architecturaux nécessaires pour le supporter efficacement étaient largement utiles. Plutôt que d'adopter le modèle d'exposition standard, Pi 1.0 met en œuvre MCP via son infrastructure Codemode existante, lui permettant de supporter le protocole tout en évitant l'encombrement du contexte auquel Zechner s'opposait initialement.

Comment cela fonctionne

Codemode agit comme une couche intermédiaire entre le modèle de langage et ses outils disponibles. Il s'exécute dans un bac à sable QuickJS, ce qui signifie qu'il fonctionne sans API Node, accès au système de fichiers, connectivité réseau ou minuteurs. Cet environnement isolé permet aux scripts d'appeler les outils et modèles de Pi, d'exécuter des opérations simultanément et de traiter les résultats avant de retourner quoi que ce soit au modèle principal.

Par défaut, Pi exclut les définitions d'outils des serveurs MCP de l'invite du modèle. Le prompt système ne reçoit qu'une description d'une ligne pour chaque serveur connecté. Lorsque l'agent doit effectuer une tâche, il utilise Codemode pour découvrir les outils appropriés, les exécuter via JavaScript et retourner uniquement la sortie pertinente. Cette approche maintient le contexte initial léger et garantit que l'utilisation des jetons évolue avec l'activité réelle plutôt qu'avec la capacité potentielle.

Les développeurs peuvent personnaliser ce comportement en utilisant un paramètre appelé toolExposure. Cette fonctionnalité permet un contrôle granulaire sur la présentation des outils. Par exemple, dans une intégration GitHub, une équipe pourrait exposer directement l'outil search_code au modèle pour un usage fréquent, garder les méthodes get_* derrière Codemode pour une découverte à la demande, et bloquer entièrement les méthodes delete_* pour prévenir toute perte accidentelle de données. Cette flexibilité permet aux ingénieurs de trouver un équilibre entre commodité, sécurité et efficacité.

Détails clés

• Chrome DevTools MCP consommait auparavant ~18 000 jetons, soit 9 % d'une fenêtre de contexte de 200k, avant toute action entreprise.
• Playwright MCP nécessitait ~13 700 jetons pour décrire ses 21 outils, représentant 6,8 % de la même fenêtre de contexte.
• Codemode s'exécute dans un bac à sable QuickJS sans API Node, système de fichiers, réseau ou accès aux minuteurs.
• Pi 1.0 réduit l'empreinte Codemode par défaut de ~5 300 jetons d'invite à ~3 300 pour les requêtes GPT-5.6.
• Un budget par défaut de 3 000 jetons est alloué aux déclarations d'outils ; les outils excédentaires restent découvrables via Codemode.
• Le paramètre toolExposure permet aux développeurs d'exposer, cacher ou bloquer des outils spécifiques par serveur.

Pourquoi c'est important

Pour les ingénieurs qui construisent des agents IA, l'efficacité de la fenêtre de contexte est une contrainte critique. Chaque jeton dépensé pour les définitions d'outils est un jeton indisponible pour l'analyse de code, le raisonnement ou l'historique. En gardant les outils MCP cachés par défaut, Pi démontre une voie viable pour supporter des écosystèmes riches sans sacrifier les performances. Cette méthode permet aux agents de se connecter à des dizaines de serveurs sans immédiatement épuiser leur budget de contexte, rendant possibles des workflows plus complexes et multi-étapes.

Le contrôle granulaire offert par toolExposure répond également aux préoccupations de sécurité et d'utilisabilité. Exposer directement tous les outils à un modèle augmente le risque d'actions involontaires, telles que la suppression de ressources ou la modification non autorisée. En forçant les outils moins critiques ou dangereux à passer par Codemode, les développeurs peuvent ajouter une couche d'examen et de traitement. Ce modèle encourage une conception plus délibérée où l'accès aux outils est adapté aux besoins spécifiques de l'agent, plutôt que d'accepter un modèle d'exposition globale.

Ce que vous pouvez faire

• Auditez vos intégrations MCP actuelles pour mesurer le coût en jetons des définitions d'outils dans vos prompts.
• Implémentez une couche de médiation similaire à Codemode pour intercepter les appels d'outils et traiter les résultats avant qu'ils n'atteignent le modèle.
• Utilisez des environnements sandboxés comme QuickJS pour exécuter la logique des outils de manière sécurisée sans accorder un accès complet au système.
• Configurez des paramètres d'exposition granulaires pour vos outils, en cachant les fonctions rarement utilisées ou à haut risque derrière des mécanismes de découverte.
• Optimisez les descriptions et la documentation des outils pour tenir dans des budgets de jetons stricts, en supprimant les déclarations redondantes.
• Testez l'impact de la dissimulation des outils sur les performances de l'agent, en veillant à ce que la latence de découverte ne nuise pas à l'expérience utilisateur.