Pourquoi nous avons rejeté une économie de 96 % de tokens

Nous avons trouvé un serveur MCP qui permet d'économiser 96 % de tokens. Il n'utilise qu'un seul outil : execute_code. Au lieu d'appeler des fonctions spécifiques, l'agent écrit du JavaScript pour obtenir des données.

Sur le papier, c'est gagnant. Pour les tâches complexes, l'exécution de code surpasse l'appel d'outils en termes d'efficacité.

Mais nous ne l'avons pas adopté. Nous avons conservé nos outils nommés et distincts à la place.

Voici pourquoi le choix évident était le mauvais choix pour notre agent.

La cible détermine la conception

La plupart des gens conçoivent des systèmes pour des modèles de pointe (frontier models) dans une fenêtre de chat. Ces modèles disposent de budgets de tokens énormes. Pour eux, l'exécution de code est reine.

Nous, nous concevons un agent orienté voix (voice-first) basé sur un petit modèle local (Hermes 3 8B) sur un bateau.

Pour un petit modèle, la contrainte n'est pas le nombre de tokens. La contrainte est la fiabilité.

Si un petit modèle a du mal à appeler un outil simple, lui demander d'écrire du JavaScript correct est une tâche bien plus difficile. execute_code sacrifie la fiabilité au profit des tokens. Nous ne pouvons pas nous permettre ce compromis.

Le problème du « dernier kilomètre »

L'exécution de code reporte le « dernier kilomètre » du travail sur l'agent. L'agent doit :

  • Filtrer les données
  • Trier les résultats
  • Formater la sortie

Nos outils effectuent ce travail à l'intérieur du serveur. Par exemple, lorsqu'on interroge l'état de la batterie, notre outil renvoie une chaîne de caractères prête pour la synthèse vocale (text-to-speech). Il dit « 68 pour cent, 12,8 volts » au lieu de chiffres bruts.

Si nous utilisons execute_code, l'agent doit écrire la logique pour formater ce discours. Les petits modèles échouent constamment à cette tâche.

La règle de l'absence

Sur un bateau, les capteurs se déconnectent. Dans notre système, un capteur manquant renvoie un null propre. Il s'agit d'un appel réussi.

Dans un modèle d'exécution de code, un capteur manquant génère souvent une erreur. Si un petit modèle tente quelques chemins erronés, cela déclenche des limites d'erreur et fait planter l'agent. Les outils nommés nous permettent de faire de l'absence un succès, et non une faute.

Liste de contrôle : Adopter vs Construire

Avant d'adopter ou de construire un serveur MCP, posez-vous ces questions :

• Quel est l'agent cible ? (Modèle de pointe vs petit modèle local) • Quelle est la contrainte déterminante ? (Tokens vs fiabilité) • Qui s'occupe du dernier kilomètre ? (L'outil formate-t-il les données ou est-ce l'agent ?) • Comment gère-t-il l'absence ? (Une valeur manquante est-elle une erreur ou un null ?) • Quel est le coût de maintenance ? (Héritez-vous d'une base de code dormante ?)

Nous n'avons pas ignoré l'autre projet. Nous en avons récolté les idées. Nous avons pris leur gestion des alarmes et leur logique de découverte de chemin pour les ajouter à notre feuille de route.

L'efficacité est une excellente chose, mais la fiabilité est indispensable lorsque l'on est en mer.

Source : https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi