---
title: "Comment les agents IA choisissent leurs outils : la mécanique de la découverte agentique"
description: "Comment Claude, ChatGPT et Cursor décident quel serveur MCP appeler. Quels signaux comptent et comment être l'outil que l'agent choisit."
canonical_url: "https://getminds.ai/blog/fr/how-ai-agents-choose-tools-mcp-discovery-mechanics"
last_updated: "2026-06-22T02:09:19.621Z"
---

# Comment les agents IA choisissent leurs outils

Quand un marketeur demande à Claude "trouve des panels synthétiques de clients pour le B2B SaaS en Allemagne", le modèle n'ouvre pas un moteur de recherche. Il lit les descriptions de chaque outil MCP actuellement connecté à la session, les classe et en choisit un. Ce classement est la nouvelle page d'accueil d'internet pour la découverte d'outils, et presque personne n'optimise pour lui.

Cet article enlève le couvercle et explique comment fonctionne réellement le ranking en 2026, quels signaux le déplacent et quelles implications pratiques cela a pour toute équipe qui shippe un serveur MCP.

## Ce que "découverte" veut dire dans un contexte agentique

Il y a deux couches de découverte qu'il faut séparer.

*Couche 1, niveau registry.* L'utilisateur (ou l'agent lui-même) trouve un serveur MCP dans un répertoire et le connecte au client. C'est de la découverte façon navigateur : registries amicaux pour agents, flux OAuth, boutons "ajouter ce connecteur". Le registry MCP, le répertoire d'Anthropic, le répertoire Apps SDK d'OpenAI et `mcpmarket.com` jouent tous ce rôle. Une fois que l'utilisateur clique sur Connecter, le serveur est dans la liste d'outils de l'agent.

*Couche 2, découverte intra-session.* Chaque fois que l'utilisateur envoie un message, l'agent doit décider quel outil, s'il y en a un, appeler. C'est la couche qui bouge réellement l'usage. Un serveur peut être connecté et ne jamais être appelé pendant des mois parce que l'agent choisit toujours autre chose. C'est ici que le vrai ranking se passe, et presque personne n'en parle.

Le reste de cet article porte sur la Couche 2.

## Ce que l'agent voit réellement

Quand un serveur MCP se connecte, il envoie un handshake décrivant chaque outil qu'il expose. Pour chaque outil, l'agent reçoit :

- Un nom (par exemple `create_panel`)
- Une description courte (1 à 3 phrases, écrites par l'auteur du serveur)
- Un schéma JSON pour les paramètres d'entrée
- Des métadonnées structurées optionnelles (annotations, exemples, type de retour)

C'est toute la surface. L'agent ne voit pas votre site web, vos prix, votre documentation ou votre blog. La pièce de texte la plus à effet de levier de tout votre produit est la chaîne de description dans l'enregistrement de votre outil.

L'implication est inconfortable : un outil brillant avec une description vague perd face à un outil médiocre avec une description nette, à chaque fois.

## Le processus de ranking, étape par étape

Quand l'utilisateur envoie un message, l'agent fait à peu près ceci :

1. *Filtrer aux outils plausiblement pertinents.* Le modèle lit son propre contexte (la conversation jusqu'ici, le dernier message de l'utilisateur) et identifie un ensemble de candidats. Avec un toolset petit (moins de 20 outils), il les considère généralement tous. Avec un toolset grand, il filtre d'abord.
2. *Noter par correspondance de description.* Pour chaque outil candidat, le modèle évalue à quel point la description correspond à l'intention de l'utilisateur. C'est un match doux, sémantique, pas un match par mot-clé. Les synonymes fonctionnent. Le langage du domaine fonctionne. Les descriptions vagues échouent.
3. *Composer un appel.* Si un outil est sélectionné, le modèle remplit les paramètres depuis le contexte de conversation. Les outils dont les schémas exigent des champs ambigus (par exemple un objet "options" non paramétré) sont pénalisés parce que le modèle est moins confiant de pouvoir les appeler correctement.
4. *Enchaîner les appels en option.* Pour les tâches multi-étapes, le modèle choisit le premier outil, l'exécute, lit le résultat et répète. Les outils qui retournent une sortie structurée et lisible par l'agent gagnent des appels de suivi. Les outils qui retournent une sortie en mur de texte bloquent la chaîne.

Tout se passe en une seule passe d'inférence. Il n'y a pas de modèle de ranker séparé. Il n'y a pas (encore) de boucle de feedback de télémétrie. La décision est prise sur la base des descriptions et du schéma, point.

## Ce qui bouge réellement le ranking

En remontant depuis le comportement observé des agents, quatre choses bougent démontrablement la sélection d'outils :

*Spécificité de la description.* "Run market research" perd face à "Run a synthetic customer panel against an audience persona and return summarized findings". La description plus longue matche plus de requêtes parce qu'elle expose plus de poignées que le modèle peut saisir. Il y a un budget (la plupart des agents tronquent les descriptions au-delà d'environ 500 caractères) mais la plupart des serveurs en sont loin.

*Structure verbe-sujet-objet.* Les agents choisissent des outils dont la description correspond au verbe utilisé par l'utilisateur. "Demande à mes clients" matche `ask_panel` mieux que `query_panel_responses`. Le nommage et la description doivent tous deux mener avec l'action.

*Forme concrète de la sortie.* "Renvoie un objet JSON avec les champs `panel_id`, `responses` et `summary`" bat "renvoie le résultat du panel". Les agents sont plus susceptibles d'appeler les outils quand ils peuvent prédire quoi faire de la sortie.

*Parsabilité du schéma.* Les schémas avec des champs requis que le modèle peut remplir depuis le contexte (descriptions de texte, comptes numériques) sont appelés. Les schémas avec des champs requis qui nécessitent un input utilisateur en milieu d'appel (jetons d'auth, IDs internes) sont sautés en faveur d'outils qui peuvent tourner de bout en bout.

## Ce qui ne bouge pas (encore) le ranking

Une liste de choses dont on parle comme si elles comptaient, mais qui ne comptent pas, en 2026 :

- *Compteurs d'étoiles dans le registry.* Découvrabilité à la Couche 1, non pertinent à la Couche 2.
- *Bourrage de mots-clés à la SEO.* Le modèle fait du match sémantique ; il ne fait pas de match par mot-clé. Bourrer "agentic research AI panels MCP" dans la description n'aide pas.
- *Reconnaissance de marque.* Le modèle n'a pas de préférence pour les marques établies par rapport aux inconnues à la couche intra-session. La qualité de la description gagne.
- *Latence sous 500 ms.* Le modèle ne chronomètre pas les appels d'outils en classant. Les outils lents mais utiles sont quand même appelés.

Cela va changer. Les scores d'eval, les signaux de satisfaction post-appel et le ranking anti-spam sont tous sur la roadmap des grands hosts. Aujourd'hui, la description est le levier.

## Le problème de l'anti-spam

La conséquence naturelle de tout cela est que n'importe qui peut gamer le ranking en écrivant une description très longue et très dense en mots-clés. Les hosts le savent. Anthropic, OpenAI et les mainteneurs du registry MCP ont tous commencé à déprécier le bourrage de description fin 2026.

Deux mécanismes anti-spam émergent :

*Validation de schéma.* Les outils dont le schéma déclaré ne correspond pas à la forme réelle de la réponse sont rétrogradés ou retirés.

*Scoring d'eval cross-host.* Le registry MCP pilote une suite d'evals publique qui exécute des prompts contre les serveurs enregistrés et reporte des scores de correction. Les serveurs qui échouent à l'eval reçoivent des avertissements, puis le retrait.

Ni l'un ni l'autre n'est totalement live mi-2026, mais les deux arrivent. La posture à prendre : écrire la description qui gagnerait dans un monde scoré qualité, pas seulement dans un monde matché par mot-clé.

## Recommandations pratiques pour les auteurs de serveurs

Si vous shippez un serveur MCP, les changements suivants amélioreront mesurablement la sélection intra-session :

1. *Réécrivez chaque description d'outil pour mener avec le verbe que l'utilisateur utiliserait.* Pas "Panel runner" mais "Run a customer research panel against a target audience and return summarized responses".
2. *Spécifiez la forme de la sortie dans la description.* "Renvoie un objet JSON avec un tableau `responses`, un champ `themes` et un champ `summary`". Cela rend l'agent assez confiant pour enchaîner des appels de suivi.
3. *Rendez les champs requis remplissables depuis le contexte.* Si un champ a besoin d'un ID interne, acceptez un nom et résolvez-le côté serveur. Les agents sautent les outils dont ils ne peuvent pas prédire les champs requis.
4. *Utilisez 200 à 400 caractères par description d'outil.* En dessous de 100 c'est trop maigre. Au-dessus de 500 c'est tronqué par la plupart des clients.
5. *Auditez votre nombre d'outils.* Les serveurs avec plus de 30 outils sont filtrés avant que l'agent ne les classe. Combinez les outils liés où c'est possible. On a vu des serveurs de 60 outils obtenir une sélection pire que ceux de 12 parce que le modèle ne voit jamais la longue queue.

Les équipes qui traitent ces descriptions comme leur copie la plus importante sont appelées. Les équipes qui les traitent comme de la plomberie de registry, non.

## Vers où ça va

La mécanique va se durcir dans les 12 prochains mois. Attendez-vous à trois changements :

*Le ranking basé sur eval passe en live.* Les scores qualité d'evals automatiques commenceront à apparaître dans les listings de registry et influenceront la sélection intra-session sur au moins un host majeur.

*Boucles de feedback de télémétrie d'agents.* Le premier host majeur à shipper "les outils qui ont produit des résultats satisfaisants dans les sessions passées sont mieux classés" va devancer les autres. C'est l'équivalent agentique du click-through-rate, et cela change la cible d'optimisation.

*Écosystèmes d'agents verticaux.* Les agents marketing, sales, recherche développeront chacun leurs propres stacks d'outils normatifs. Être le défaut dans votre vertical comptera plus que d'être dans tous les répertoires.

Les outils qui gagnent dans cette transition sont ceux qui traitent leurs descriptions MCP comme la page d'accueil de leur produit. Les outils qui ne le font pas, ne seront pas appelés, peu importe la qualité du service sous-jacent.

---

Pour le contexte plus large sur pourquoi les agents sont les nouveaux acheteurs, voir [les agents IA sont les nouveaux acheteurs marketing](/blog/ai-agents-new-marketing-buyer-agentic-discovery). Pour la mise en place pratique, voir [comment faire tourner des panels clients depuis Claude, ChatGPT ou Cursor](/blog/run-customer-panels-from-claude-chatgpt-cursor-mcp-guide). Pour voir à quoi ressemble un serveur MCP bien décrit en production, voir [Minds MCP](/mcp/overview).