Les petits outils de navigateur composables surpassent le MCP en efficacité des jetons et en contrôle du développeur.

Introduction

Le débat sur la nécessité ou non pour les développeurs de disposer de serveurs MCP (Model‑Centric Programming) complets pour les tâches quotidiennes des agents s’est intensifié dans les communautés IA, Twitter et développeurs. La question centrale est simple : les outils légers et composables que les agents comprennent déjà peuvent-ils remplacer les manifestes MCP lourds tout en économisant des tokens et en préservant la flexibilité ? Cet article examine une boîte à outils minimaliste construite autour de Bash et de petits scripts Node, la compare aux implémentations MCP populaires et décrit des flux de travail pratiques pour les développeurs solo et les petites équipes.

Efficacité des tokens : le vrai coût des manifestes MCP

Comment le MCP consomme les tokens

Les serveurs MCP populaires comme Playwright MCP et Chrome DevTools MCP livrent d’importants catalogues d’outils. Par exemple :

• Playwright MCP – 21 outils, ~13 700 tokens (≈ 6,8 % de la fenêtre de contexte de Claude)
• Chrome DevTools MCP – 26 outils, ~18 000 tokens (≈ 9 % de la fenêtre de contexte)

Ces tokens sont consommés avant même que le travail réel ne commence. Lorsque plusieurs serveurs MCP sont combinés, le surcoût en tokens se multiplie, et les agents doivent analyser des descriptions d’outils verbeuses, ce qui entraîne confusion et perte de composabilité.

L’avantage de la boîte à outils minimale

Une alternative légère consiste en un README concis (≈ 225 tokens) accompagné de quelques scripts Node qui utilisent Puppeteer Core. Comme les agents comprennent déjà Bash et JavaScript, ils peuvent invoquer ces scripts directement sans recourir à de vastes catalogues de compétences. Le résultat est une empreinte en tokens de deux ordres de grandeur plus petite que celle des manifestes MCP traditionnels, en accord avec la philosophie Unix classique des outils petits et composables.

À l’intérieur de la boîte à outils navigateur minimale

La boîte à outils comprend six scripts, chacun remplissant un rôle bien défini.

start.js

• Lance Chrome avec un profil neuf ou cloné.
• Termine tout processus Chrome existant, crée un répertoire temporaire de données utilisateur et démarre Chrome avec le débogage à distance sur le port 9222.
• Réessaie de se connecter via puppeteer.connect jusqu’à succès, puis affiche un message de confirmation.

Ce démarrage déterministe élimine le besoin de schémas RPC complexes et fournit un contrat simple et fiable pour l’agent.

nav.js

• Syntaxe : nav.js <URL> [new]
• Navigue l’onglet actif (ou ouvre un nouvel onglet si new est indiqué) et attend DOMContentLoaded.
• Retourne un message d’état clair tel que « opened » ou « navigated ».

Le script reflète la façon naturelle dont les agents pensent aux actions sur une page : « aller à cette page » sans une prolifération de variantes clic, survol ou défilement.

evil.js

• Exécute du JavaScript arbitraire dans le contexte de la page.
• Utilisation : evil.js "document.querySelectorAll('a').length"
• Construit une fonction asynchrone, évalue le code et imprime les résultats sous forme de paires clé‑valeur (pour les objets/ tableaux) ou comme une valeur scalaire.

En permettant aux agents d’écrire du code DOM natif, evil.js supprime le surcoût en tokens lié à la description de chaque interaction possible et autorise l’extraction directe de données sans diffuser de gros résultats via le prompt.

screenshot.js

• Capture une capture d’écran du viewport de la page active.
• Enregistre l’image dans le répertoire temporaire du système avec un nom horodaté et affiche le chemin du fichier.
• L’agent peut alors lire l’image et appliquer des modèles de vision au besoin.

Stocker les images sous forme de fichiers plutôt que de les intégrer au prompt réduit drastiquement la consommation de tokens.

pick.js

• Propose un sélecteur visuel interactif.
• Affiche une bannière et un rectangle de mise en évidence qui suit le curseur ; un clic sélectionne un élément, Ctrl/Cmd+Click active la multi‑sélection, Enter valide, et Esc annule.
• Retourne des informations structurées pour chaque élément sélectionné : balise, ID, classe, texte tronqué, chaîne de sélecteur CSS et un extrait de l’HTML externe.

Cet outil fait le lien entre l’intention humaine et le code, permettant aux agents de générer des sélecteurs fiables pour les scrapers ou les scripts d’automatisation.

Scripts d’assistance

Des utilitaires supplémentaires (par ex. un helper de cookies) complètent la boîte à outils, gérant les tâches courantes du navigateur sans alourdir le budget de tokens.

Construire un flux de travail fluide

1. Créer un répertoire dédié (par ex. ~/agent-tools).
2. Cloner chaque dépôt d’outil dans ce dossier.
3. Ajouter le répertoire à votre PATH via un alias shell ou une variable d’environnement afin que l’agent puisse invoquer les scripts directement.
4. Référencer le README dans le contexte de l’agent uniquement lorsque c’est nécessaire, afin de garder le prompt léger.
5. Définir le répertoire des outils comme répertoire de travail pour Claude ou d’autres interfaces LLM, permettant l’inclusion à la demande des définitions d’outil.

En suivant ces étapes, les agents fonctionnent avec un jeu de commandes minimal, évitent les changements de répertoire constants et n’ont plus besoin de manifestes de compétences massifs.

Quand le MCP reste pertinent

Les environnements d’entreprise restreignent souvent l’accès direct aux API ou au système de fichiers. Dans ces cas, un serveur MCP peut jouer le rôle de courtier à garde‑fou, offrant :

• Des permissions basées sur les rôles
• Une traçabilité des récupérations de données
• Une exposition contrôlée des services internes

Cependant, même dans ces scénarios, les développeurs doivent surveiller l’empreinte en tokens des descriptions d’outils du serveur MCP. Un manifeste de 13 – 18 k tokens consomme toujours une part notable de la fenêtre de contexte, il reste donc préférable de garder les descripteurs concis et de déléguer les gros résultats à des fichiers.

Conclusion

La boîte à outils minimaliste montre que de petits scripts composables peuvent offrir la même – voire une meilleure – fonctionnalité que les serveurs MCP lourds, tout en réduisant drastiquement la consommation de tokens et en augmentant le contrôle du développeur. Pour les développeurs solo et les petites équipes, l’approche recommandée est :

• Utiliser start.js, nav.js, evil.js, screenshot.js, pick.js et les helpers associés.
• Conserver les définitions d’outil dans un README concis et les invoquer via Bash.
• Réserver les serveurs MCP aux environnements nécessitant une gouvernance stricte ou une exposition d’API limitée.

En adoptant la philosophie Unix du « faire une chose et bien le faire », les agents restent rapides, économiques et adaptables — précisément les qualités requises pour le développement moderne assisté par l’IA.