Les agents se comportent différemment via MCP et CLI, et la méthode DART apporte jusqu'à +9 points

Lorsqu'un agent IA utilise des outils, il ne voit pas des capacités « brutes », mais leur description : soit un ensemble de fonctions exposées via le protocole MCP (Model Context Protocol, standard de connexion des outils à un modèle de langage), soit des commandes dans un terminal, c'est-à-dire la CLI. Une équipe de ModalityDance (Zhenning Shi, Liang Pang, Yongqi Li) a posé une question directe : si les capacités sont strictement identiques et que seule la manière de les présenter au modèle change, le comportement de l'agent change-t-il ? Réponse : oui, et fortement.

La qualité de résolution des tâches, la consommation de tokens (les unités de texte facturées lors de l'utilisation d'un modèle) et même la manière dont l'agent se trompe et se rétablit après une erreur divergent. Les auteurs proposent par la même occasion la méthode DART, qui améliore les résultats dans les six configurations testées, jusqu'à 9,0 points.

Comment rendre la comparaison équitable

On compare généralement MCP et CLI « tels quels ». Mais on ne sait alors pas ce qui a influencé le résultat : l'interface elle-même, ou le fait que l'une dispose d'outils plus riches et que l'autre les implémente différemment. Pour lever cette ambiguïté, les auteurs ont construit le banc d'essai MICA (Matched Interface Comparison and Analysis, « comparaison et analyse d'interfaces appariées »).

Son fonctionnement :

• un contrat unique d'actions sémantiques : la liste de tout ce que l'agent peut faire ; • deux versions, MCP et CLI, sont générées automatiquement à partir de ce contrat ; • quel que soit le choix de l'agent, l'action est décodée puis envoyée au même code d'exécution.

Sous le capot, les capacités sont donc strictement les mêmes. La différence ne tient qu'à la « vitrine » : la manière de décrire les actions, la manière de les écrire et l'aspect de la réponse de l'environnement. Les tests ont été menés sur six modèles dans trois environnements interactifs.

Où les trajectoires de l'agent divergent

Premier résultat : la performance et le coût de l'interaction diffèrent nettement. Et il ne s'agit pas seulement de fautes de syntaxe, lorsque l'agent écrit mal un appel. L'interface influe sur l'action que l'agent choisit sur le fond, sur la façon dont il échoue et sur la façon dont il se rétablit après une défaillance.

Pour identifier la source de cette sensibilité, les chercheurs ont employé deux approches.

• Sondes à état identique. L'agent était placé dans la même situation, et trois paramètres variaient séparément : la représentation des capacités, l'écriture de l'action et le retour d'information. Cela a permis de voir laquelle de ces trois composantes déstabilise le plus le modèle. • Trajectoires naturelles appariées. L'agent résolvait la même tâche via MCP et via CLI. Sur 2004 épisodes, une divergence structurelle apparaît dans 94,3% des cas, soit environ 1890. Les écarts précoces ne s'effacent pas, ils se prolongent : une seule étape ratée au début modifiait tout le reste de l'interaction.

Conclusion des auteurs : l'interface fait partie de la boucle fermée de prise de décision. L'agent agit, reçoit une réponse, décide à nouveau, et la forme de la réponse comme celle de l'écriture influent sur chaque étape suivante. Ce n'est pas une enveloppe neutre autour du modèle.

DART : réparer l'écriture de la commande, pas la décision

Puisque l'écart naît à l'étape de « réalisation » de l'action, c'est là qu'on peut le corriger. La méthode DART (Decoupled Action Realization and Targeted Repair, « réalisation d'action découplée et réparation ciblée ») répartit le travail en deux parties. D'abord, l'agent détermine ce qu'il veut faire exactement. Cette décision sémantique est vérifiée et conservée. Ensuite, une étape distincte se charge de l'écrire dans le langage de l'interface concernée et, en cas d'erreur, ne répare que cette écriture. Le sens de l'action choisie n'est pas remis en cause.

Effet, d'après les chiffres annoncés :

• le score dans les benchmarks progresse dans les six configurations testées (modèle plus environnement), de 9,0 points au maximum ; • le coût de MCP baisse dans les trois environnements, de 27,1 mille tokens par tâche au maximum.

Le second chiffre compte pour le budget. Les descriptions d'outils et les réponses MCP sont souvent verbeuses, et il faut les faire transiter par le contexte à chaque étape. Si une partie du travail n'est pas répétée, la consommation baisse sensiblement.

Ce que cela implique pour les ingénieurs

Le débat « MCP contre CLI » posé en ces termes perd son sens : on ne peut tout simplement pas désigner de vainqueur sans contrôler la manière dont l'interface est implémentée. Un même modèle avec les mêmes outils peut paraître plus ou moins performant selon la forme de présentation.

Conclusions pratiques :

• lorsque vous comparez des modèles et des frameworks d'agents, fixez l'interface et décrivez-la dans le rapport, faute de quoi les chiffres ne sont pas comparables ; • il vaut mieux analyser les défaillances d'un agent par niveaux : s'est-il trompé dans le choix de l'action, ou seulement dans l'écriture de l'appel ; • si vous construisez un agent sur MCP et payez les tokens, il est pertinent de séparer la décision sémantique de sa mise en forme et de ne corriger que la mise en forme.

Les limites sont aussi visibles : l'étude couvre six modèles et trois environnements, il faut donc transposer les chiffres avec prudence à tout autre ensemble de tâches. Le code et la page du projet sont ouverts (dépôt ModalityDance/MICA sur GitHub), de sorte que les résultats peuvent être vérifiés sur vos propres agents.