Cursor avertit au-delà de 40 outils MCP, VS Code rejette les requêtes au-delà de 128, et Claude Code diffère les définitions grâce à la recherche d’outils. Cet article détaille chaque limite, le coût en tokens par outil et les solutions qui maintiennent une configuration chargée sous le plafond.
Ajoutez un serveur MCP de plus et votre agent peut soudain oublier comment lire un fichier. Pas de plantage, pas de bandeau rouge, juste un outil qui était là hier et qui manque aujourd’hui. C’est la limite d’outils MCP à l’œuvre, et chaque éditeur la gère différemment. Cursor vous avertit au-delà de 40 outils, VS Code rejette les requêtes au-delà de 128, et Claude Code diffère discrètement la plupart des définitions d’outils jusqu’à ce que le modèle les demande.
Cet article vous donne les vrais chiffres pour chaque client, les messages que vous verrez en franchissant la limite, le calcul des tokens derrière ces limites, et une courte liste de solutions pour garder une configuration chargée sous le plafond.
💡 En bref : prévoyez 40 outils dans Cursor, 128 dans VS Code et 100 dans Windsurf. Considérez Claude Code comme « aucun nombre fixe, mais chaque définition coûte tout de même du contexte, sauf si la recherche d’outils est activée ». Les limites évoluent d’une version à l’autre, vérifiez donc avec la version que vous avez installée.
Voici ce que rapportent la documentation officielle et les discussions de la communauté en octobre 2026.
| Client | Limite d’outils | Ce qui se passe au-delà |
|---|---|---|
| Cursor | 40 outils pour l’ensemble des serveurs MCP activés | Un avertissement s’affiche et seuls les 40 premiers outils atteignent l’agent |
| VS Code (Copilot Chat) | 128 outils par requête de chat | Erreur : « Cannot have more than 128 tools per request » |
| Windsurf (Cascade) | 100 outils pour l’ensemble des serveurs | Les outils en trop sont indisponibles tant que vous n’en désactivez pas |
| Claude Code | Aucun nombre fixe | La recherche d’outils diffère les définitions par défaut ; la désactiver charge tout d’emblée |
| Claude Desktop | Aucun plafond strict publié | Chaque définition d’outil activée entre dans le contexte de la conversation |
Deux points ressortent. D’abord, VS Code est le seul client de ce tableau dont le chiffre figure dans la documentation officielle. Les 40 de Cursor et les 100 de Windsurf proviennent de fils de forum et d’articles tiers, ce qui justifie une mention « vérifiez votre version ». Ensuite, le plafond strict est rarement votre premier problème. Des réponses plus lentes, de mauvais choix d’outils et une fenêtre de contexte qui se remplit avant même que vous ayez tapé un prompt apparaissent bien avant d’atteindre n’importe quel plafond.
Un serveur MCP décrit chaque outil avec un nom, une description en langage courant et un schéma JSON pour ses arguments. Le client envoie l’ensemble de ce bloc au modèle à chaque requête, avant votre prompt et avant le contenu de tout fichier. Dix petits outils passent presque inaperçus. Quatre-vingts outils verbeux peuvent absorber une part réelle de la fenêtre que vous vouliez réserver au code.
C’est la véritable raison pour laquelle les clients fixent des plafonds. Une limite est un moyen brutal de protéger le budget de contexte, de réduire la latence et d’éviter que le modèle ne se noie dans les options. Les fils de forum de Cursor décrivent la limite de 40 outils exactement en ces termes : transmettre des dizaines d’outils bruts oblige le modèle à consommer du contexte pour les évaluer, si bien que la latence augmente et la précision baisse.
Le contexte n’est qu’une moitié de l’histoire. L’autre moitié, c’est le choix. Lorsqu’un modèle fait face à des dizaines d’outils aux noms qui se recoupent, comme search_issues, search_repos et search_code, il doit deviner celui qui convient, et les erreurs se multiplient à mesure que la liste s’allonge.
La documentation d’OpenAI sur l’appel de fonctions recommande de viser moins de 20 fonctions disponibles au début d’un tour, et qualifie cette recommandation de simple suggestion. GitHub est arrivé à un résultat semblable dans Copilot : il a réduit l’ensemble d’outils intégrés par défaut de 40 à 13 outils essentiels, et a chargé les autres à la demande. Selon les propres benchmarks de GitHub, cette approche a amélioré les taux de réussite de 2 à 5 points de pourcentage et réduit la latence moyenne de 400 millisecondes.
La limite pratique se situe donc sous le plafond affiché. Un serveur avec 12 outils aux noms bien distincts fait souvent mieux qu’un serveur de 90 outils qui se ressemblent tous.
Vous pouvez mesurer vous-même la confusion entre outils en une dizaine de minutes, sans toucher à la configuration de votre éditeur.
Répétez l’expérience avec plusieurs modèles côte à côte. Claude Sonnet 5, GPT 5.4 et Gemini 3.1 Pro sont tous disponibles comme modèles de chat sur PicassoIA, ce qui vous permet de comparer leur façon de gérer une liste chargée. Si les mauvais choix chutent nettement quand la liste diminue, vous savez combien d’outils votre flux de travail peut réellement gérer.
💡 Mise en garde : ce test évalue le choix du modèle à partir de texte brut. Les vrais clients ajoutent leur propre routage, considérez donc le résultat comme un indicateur, et non comme une garantie.
Cursor affiche un avertissement lorsque les outils de vos serveurs activés dépassent 40. Le message signalé sur le forum de Cursor ressemble à ceci : vous avez 50 outils provenant de serveurs activés, la limite est de 40, et certains outils peuvent ne pas être disponibles pour l’agent. Dans les versions plus anciennes, les outils excédentaires étaient tout simplement ignorés. Avec des serveurs exposant 45 outils au total, l’agent en utilisait 40, sans diagnostic détaillé indiquant lesquels cinq avaient disparu.
Certains articles récents affirment que les versions récentes de Cursor enregistrent les outils de façon plus souple et en chargent certains à la demande. La page de documentation MCP que nous avons consultée ne publie aucun nombre d’outils, donc 40 reste le chiffre sûr pour la planification.
💡 Vérifiez le calcul : la limite est totale, pas par serveur. Trois serveurs de 15 outils chacun vous placent déjà à 45, soit cinq au-delà de la limite, alors qu’aucun serveur pris isolément ne semble volumineux.
Quatre actions, classées de la moins à la plus exigeante :
.cursor/mcp.json et ne gardez que vos serveurs du quotidien dans le fichier global ~/.cursor/mcp.json.La désactivation outil par outil est une demande de fonctionnalité qui revient souvent sur le forum de Cursor. Si vous avez besoin de cette granularité aujourd’hui, vous devrez élaguer au niveau des serveurs.
VS Code est le plus explicite des trois. Sa documentation indique qu’une requête de chat peut avoir au maximum 128 outils activés à la fois. Au-delà, Copilot Chat échoue avec le message : « Cannot have more than 128 tools per request ».
Le compte porte sur tout ce qui est activé dans le sélecteur d’outils, et pas seulement sur les outils MCP, si bien qu’il se remplit plus vite qu’on ne le pense. Deux ou trois gros serveurs peuvent suffire.
La solution rapide se trouve dans le sélecteur d’outils de la vue Chat. Décochez des outils individuels ou des serveurs MCP entiers jusqu’à ce que le compte passe sous 128, puis renvoyez la requête.
Si vous voulez dépasser 128, VS Code propose les outils virtuels. Définissez github.copilot.chat.virtualTools.threshold et VS Code regroupe les outils similaires sous un seul outil virtuel. Le modèle voit d’abord les groupes et n’en développe un que lorsque le prompt en a besoin, ce qui permet à une requête de chat de dépasser la limite de 128.
Pensez-y comme à une table des matières : le modèle lit les titres des chapitres, puis ouvre un seul chapitre. Le compromis est une étape de chargement supplémentaire la première fois qu’un groupe est nécessaire, en échange d’une liste de départ beaucoup plus courte.
Les tests de GitHub sur le routage fondé sur les embeddings montrent pourquoi le regroupement est payant. L’outil nécessaire était disponible dans 94,5 % des cas, contre 87,5 % pour une sélection par LLM et 69,0 % pour une liste d’outils statique.
Claude Code emprunte une autre voie. Au lieu de limiter le nombre, il évite de payer chaque définition dès le départ. Avec la recherche d’outils, les définitions des outils MCP sont retenues hors de la requête, et le modèle reçoit un seul outil de recherche pour charger ceux dont il a besoin. La documentation MCP d’Anthropic liste les exceptions : la recherche d’outils est désactivée avec un ANTHROPIC_BASE_URL personnalisé, avec ENABLE_TOOL_SEARCH=false, et avec les modèles antérieurs à la génération Claude 4.5.
Des articles communautaires décrivent d’autres valeurs pour la même variable, comme auto, qui ne diffère que lorsque les définitions dépassent 10 % de la fenêtre de contexte, et auto:5 pour un seuil de 5 %. Vérifiez la documentation de votre version installée avant de vous y fier. Un article a mesuré 147 définitions d’outils pour environ 90 000 tokens lorsqu’elles sont chargées d’emblée, contre environ 15 000 avec la recherche d’outils activée.
La taille des sorties compte aussi. Claude Code avertit lorsqu’un seul résultat d’outil MCP dépasse 10 000 tokens et plafonne la sortie à 25 000 par défaut. Ne l’augmentez avec MAX_MCP_OUTPUT_TOKENS que lorsqu’une tâche en a vraiment besoin.
Nous n’avons pas trouvé de nombre fixe d’outils pour Claude Desktop dans la documentation d’Anthropic. Des articles tiers décrivent un mécanisme plus simple : chaque outil exposé par chaque serveur connecté est injecté dans le contexte de la conversation pour chaque message, sans récupération dynamique. Leur conseil pratique est de rester entre 30 et 50 outils actifs avant que la saturation et la confusion ne s’installent. Considérez cette plage comme une expérience communautaire, et non comme une limite officielle.
La leçon pour les utilisateurs de Claude est que la limite est un budget, pas un nombre. Activez uniquement les connecteurs dont la conversation en cours a besoin, et désactivez les autres.
Les chiffres publiés varient beaucoup, car le niveau de détail des schémas varie. Ces valeurs proviennent de listes publiques de coûts en tokens et de l’article mentionné plus haut :
| Serveur ou configuration | Définitions d’outils | Tokens au départ | Par outil (environ) |
|---|---|---|---|
| Serveur MCP GitHub | 86 | 14 406 | environ 170 |
| Variante plus petite du serveur GitHub | 36 | 11 430 | environ 320 |
| Serveur GitHub Projects | 19 | 2 316 | environ 120 |
| Configuration mixte d’un article | 147 | environ 90 000 | environ 610 |
C’est l’écart qui est instructif. Un outil coûte entre environ 120 et 610 tokens selon le volume de sa description et de son schéma. Comptez les outils, mais pesez-les aussi.
Utilisez-la pour vérifier rapidement n’importe quelle configuration :
outils × tokens par outil ÷ fenêtre de contexte = part consommée avant de taper quoi que ce soit
| Outils | Tokens chacun | Total | Part d’une fenêtre de 200 000 |
|---|---|---|---|
| 10 | 300 | 3 000 | 1,5 % |
| 40 | 300 | 12 000 | 6 % |
| 86 | 170 | 14 620 | 7,3 % |
| 128 | 600 | 76 800 | 38,4 % |
La fenêtre de 200 000 n’est qu’un exemple, et votre modèle peut en proposer davantage ou moins. La tendance reste la même : 40 outils légers coûtent environ 6 %, tandis que 128 outils lourds peuvent absorber plus d’un tiers. Le poids des schémas compte plus que le nombre affiché sur le plafond.
Classez chaque outil dans trois ou quatre tâches, par exemple le code, les données, la documentation et les médias. Activez ensuite une tâche à la fois. Dans Cursor, cela passe par la configuration de chaque projet, dans VS Code par le sélecteur d’outils, et dans Claude par les interrupteurs des connecteurs.
Le regroupement règle aussi les collisions de noms. Lorsque les outils de documentation et les outils de code ne partagent jamais une même conversation, search ne peut signifier qu’une seule chose.
La plupart des configurations embarquent du poids mort. Parcourez cette liste une fois :
💡 Règle empirique : si un outil n’a pas été appelé depuis un mois, il consomme des tokens sans rien vous apporter.
Si vous écrivez votre propre serveur MCP, concevez-le en fonction du budget : une seule tâche, des descriptions courtes, des noms qui ne se chevauchent jamais et des schémas d’arguments serrés. Le connecteur PicassoIA pour Claude illustre bien l’approche légère. Il expose neuf outils : generate_image, edit_image, deux générateurs de vidéos, get_generation, list_generations, list_models, get_account et cancel_generation. Tous servent à une seule tâche, créer des images et des vidéos.
Un serveur de cette taille tient confortablement sous les plafonds de Cursor (40) et de Windsurf (100), et laisse de la place pour une demi-douzaine d’autres serveurs avant que vous ne ressentiez la moindre pression.
La meilleure façon de constater ce qu’apporte un budget d’outils bien ordonné est de faire passer un vrai flux de travail par ce dispositif. Demandez une image en langage courant, vérifiez le résultat, ajustez un détail, relancez. Une configuration ciblée garde cette boucle rapide, car le modèle n’a pas à parcourir soixante outils sans rapport pour trouver celui dont il a besoin.
Les photos de cet article ont été réalisées avec P-Image et des prompts courts et précis. Vous pouvez tester le même type de prompts sur Picasso IA dès maintenant :
Picasso IA peut aussi transformer une image fixe en courte vidéo, ce qui permet à la même photo de devenir un clip en une étape de plus. Parcourez tous les modèles sur picassoia.com/en/all-models, choisissez-en un, rédigez un prompt sur votre propre projet, et voyez ce que vous obtenez. Modifiez un mot, relancez, puis comparez. Cette petite habitude de tester une seule variable à la fois est la même que celle qui garde une configuration MCP en bonne santé.
Choisissez votre langue
