Lorsqu’un agent IA dispose de 1 000 outils MCP : sélection, contexte et compétences

Plus d’outils à disposition pour un agent IA semble être un avantage indéniable, du moins tant que leur nombre reste inférieur à 1 000. À ce stade, la question change : elle cesse d’être « L’agent peut-il faire cela ? » pour devenir « L’agent peut-il trouver l’outil adéquat et l’utiliser correctement ? » C’est là que MCP devient intéressant.

MCP facilite l’exposition des outils

Un atout majeur du Model Context Protocol est le fait que les capacités atteignent les agents via une interface commune. Un produit SaaS peut publier create_customer, get_customer, update_customer, create_invoice, refund_payment et search_orders. Un autre serveur MCP peut gérer GitHub, un troisième Slack, et un quatrième une base de données interne. Chacun fonctionne bien seul. Les problèmes commencent lorsque un agent se connecte à de nombreux serveurs et que le nombre total augmente rapidement. Dix outils, ce n’est rien ; cent outils commencent à poser des difficultés ; et mille outils représentent un problème de nature différente.

L’explosion des outils

Placez-vous à la place de l’agent disposant de 1 000 outils. Vous devrez déterminer quelle est la fonction de chacun, lesquels sont liés, lesquels utiliser, quels paramètres chacun accepte, lesquels doivent être exécutés en premier et si plusieurs outils accomplissent la même tâche. Techniquement, l’agent peut accéder à tout, mais l’accès ne signifie pas une utilisation aisée. Plus d’outils signifie plus de capacités et aussi plus de choix, et plus de choix peuvent rendre le choix plus difficile.

Le contexte s’affiche

Chaque outil nécessite une description. Pour un outil, il s’agira peut-être simplement d’un nom :

create_invoice

et une courte définition :

Creates an invoice for a customer.Parameters:
- customer_id
- amount
- currency
- due_date

Multipliez cela par 1 000. Même de courtes descriptions génèrent une grande quantité de contexte, de sorte que des tokens sont consommés rien que pour indiquer au modèle ce qu’il peut faire, et la plupart de ces outils n’ont rien à voir avec la tâche en cours. Si un utilisateur demande le statut d’une commande, il n’y a aucune raison pour que l’agent prenne en compte 500 outils de facturation, GitHub, CRM et déploiement.

Choisir l’outil adéquat est la véritable difficulté

Supposons que l’agent voie ceux-ci :

get_customer
get_customer_details
lookup_customer
search_customer
find_customer

Tous ont un son similaire. Lequel doit-il appeler ? Imaginez maintenant cela appliqué à des centaines d’outils. Le modèle peut appeler les outils sans problème. Ce qui est difficile, c’est de choisir parmi une multitude d’outils. C’est comme donner à un développeur 10 000 fonctions en lui souhaitant bonne chance. C’est possible, mais pas agréable.

Plus d’outils, plus d’erreurs

Le choix n’est souvent pas binaire, car plusieurs outils peuvent fonctionner :

search_orders
get_order
list_orders
find_order_by_customer

Un agent peut choisir un outil valide et l’utiliser de manière inefficace, appeler plusieurs outils alors qu’un seul suffirait, ou les appeler dans le mauvais ordre. La chaîne complète s’étend de la disponibilité des outils à leur sélection, puis à leur mise en séquence, enfin à leur exécution. MCP aide principalement au premier maillon. Le reste dépend de l’agent et de l’architecture qui l’entoure.

Les agents devraient-ils disposer de moins d’outils ?

Pas nécessairement. L’objectif n’est pas de limiter ce qu’un agent peut faire, mais d’éviter de le forcer à comprendre tout en même temps. Une personne qui résout un problème de paiement n’ouvre pas tous les outils internes pour lire la documentation ; elle utilise uniquement ceux liés aux paiements. Les agents pourraient fonctionner de la même manière. Le modèle consistant à charger tout d’abord avant de choisir pourrait être remplacé par un processus de découverte, de sélection, de chargement et d’exécution, ce qui représente une conception plus intéressante.

Le rôle des compétences

Les compétences sont directement liées. Une compétence peut fournir le contexte nécessaire pour un type de tâche donné. Par exemple, une compétence liée à la facturation des clients peut indiquer à l’agent de trouver le client, de vérifier son abonnement, d’examiner les factures en souffrance, de déterminer la procédure de facturation appropriée, de demander une approbation si nécessaire, puis d’utiliser l’outil correspondant.

L’agent n’a plus à réfléchir à chaque outil présent dans le système : il reçoit un ensemble plus restreint et plus pertinent pour sa tâche. Au lieu de cela :

Agent
 ↓
1,000 tools

Le flux pourrait être le suivant :

Agent
 ↓
Relevant Skill
 ↓
Relevant tools
 ↓
MCP
 ↓
API / System

Les compétences ne remplacent pas MCP, car elles traitent des problèmes différents. MCP relie l’agent aux capacités, tandis que les compétences peuvent lui apprendre à les utiliser. L’idée de privilégier les compétences par rapport à MCP reste expérimentale et en évolution ; il est donc préférable de la considérer comme une orientation émergente plutôt que comme une architecture définitive.

Les passerelles peuvent également être importantes

Une autre orientation concerne la passerelle MCP. Au lieu de relier directement un agent à des dizaines de serveurs MCP, une passerelle se situe entre eux :

Agent
 ↓
MCP Gateway
 ↓
MCP Servers
 ↓
APIs / Systems

Un gateway pourrait potentiellement assumer les fonctions d’authentification, de routage, de contrôle d’accès, d’observabilité, de découverte d’outils ainsi que la gestion de nombreux serveurs. Sa valeur augmente à mesure que les déploiements MCP deviennent plus importants.

Le véritable problème, c’est l’irrélevance

Le souci n’est pas tant l’existence de 1 000 outils en soi, mais plutôt celle de 1 000 outils irrelevants. Si une tâche nécessite réellement mille outils, qu’il en soit ainsi. Si elle n’en nécessite que douze mais que l’agent doit traiter mille outils pour les trouver, c’est une complexité inutile. Le principe : les agents n’ont pas besoin d’accéder à tout, seulement à ce qui est important au moment présent.

Cela deviendra probablement une préoccupation centrale dans l’architecture MCP à mesure que les agents se connectent à davantage de systèmes. MCP a résolu la première question : comment donner aux agents un accès standardisé aux outils. La question suivante concerne la manière de gérer intelligemment tous ces outils, ce qui semble considérablement plus difficile. Fournir des outils aux agents est devenu simple. Fournir les bons outils au bon moment reste la tâche à accomplir.