Yandex compare MCP et CLI+Skill pour les agents IA : 400 requêtes et une panne inattendue

L'équipe Services urbains de Yandex a réalisé un benchmark comparant deux façons de connecter un agent IA à des API internes, et constaté que le choix d'architecture influe directement sur l'efficacité avec laquelle les tokens sont dépensés.

Le problème : les tokens ne sont pas infinis

La fenêtre de contexte est limitée, tout le monde le sait. Mais peu de gens comptent combien de tokens partent non pas dans la tâche elle-même, mais dans l'« habillage » : descriptions d'outils, listes de paramètres, résultats intermédiaires des appels. Dans les scénarios complexes, ces frais généraux peuvent occuper une part importante du contexte disponible. L'agent se met alors à se tromper, non parce que le modèle est mauvais, mais simplement parce qu'il ne reste plus d'espace utile.

Daniil Mikhailov, de l'équipe des produits partenaires de Yandex, a posé la question sans détour : comment faire plus en dépensant moins de tokens avec de vraies API internes ?

MCP contre CLI + Skill

L'équipe a comparé deux manières d'intégrer un agent à des outils.

MCP (Model Context Protocol) est un protocole structuré : l'agent reçoit la description de chaque outil dans un format explicite, et les appels passent par une couche standardisée. L'avantage : l'universalité et un schéma prévisible. L'inconvénient : chaque description d'outil occupe intégralement de la place dans le contexte.

CLI + Skill est une approche alternative : l'agent passe par la ligne de commande, et la connaissance des outils est intégrée dans un « skill » compact, un prompt d'instructions rédigé à l'avance. La description est plus compacte, mais il faut la maintenir à la main.

Pour tester une hypothèse tirée de recherches externes, l'équipe a monté un benchmark :

• 14 scénarios réels d'utilisation des outils internes de Yandex
• 2 modèles de langage
• Plus de 400 requêtes
• Mesures de précision et de consommation de tokens dans chaque scénario

Le moment où tout s'est cassé

Le plus précieux s'est produit non pas à la fin, mais au milieu de l'expérience : ce qui fonctionnait de façon stable a soudain cessé de fonctionner. Selon Mikhailov, cette panne s'est révélée plus intéressante que les chiffres finaux, et il a fallu en chercher les causes.

« À un moment, tout ce qui marchait s'est cassé, et c'est devenu le plus intéressant.

Il a fallu comprendre pourquoi. »

Ces anomalies dans les benchmarks mettent souvent au jour des dépendances cachées : la manière dont le modèle interprète le format du schéma, le comportement des outils lors d'appels répétés, la stabilité de la sortie selon les formulations de la tâche. Sans ce moment de stress, les résultats auraient pu être naïvement optimistes.

Le résultat : un arbre de décision

À l'issue de la série d'expériences, l'équipe a établi un arbre de décision pratique : quand MCP est plus avantageux, et quand c'est CLI + Skill. Ce n'est pas une recommandation abstraite, mais une conclusion tirée de données réelles : plus de 400 requêtes sur une infrastructure réelle.

Ce que cela signifie

Choisir comment connecter un agent à une API n'est pas un caprice technique. Ce choix détermine combien de tokens sont gaspillés, combien de temps le contexte tient et la stabilité de l'agent dans les scénarios hors normes. Pour les équipes qui construisent des agents produit au-dessus de systèmes internes, cette étude fournit un outil concret pour choisir l'architecture, fondé sur des mesures réelles plutôt que sur des arguments marketing.