126 Outils MCP : pourquoi ce n'est pas la meilleure solution pour l'agent

Ceci est une série en 10 parties expliquant comment Apidog a développé Apidog CLI, un outil en ligne de commande pour le test d'API et la gestion du cycle de vie des API. Lisez dans l'ordre ou accédez à n'importe quel article qui vous intéresse :

Lorsque le MCP est devenu le point chaud de l'industrie, nous avons construit un serveur MCP complet avec 126 outils générés. Voici ce qui n'a pas fonctionné – et pourquoi plus d'outils ne signifie pas une meilleure activation des agents.

Le battage médiatique du MCP

Début 2025, le MCP (Model Context Protocol) est devenu un point chaud de l'industrie.

Anthropic a promu le protocole. Cursor, Claude Code, Antigravity, divers IDE d'agents et de nombreux produits SaaS ont rapidement suivi. Le protocole promettait un moyen standardisé pour les agents IA de se connecter à des outils externes et des sources de données.

Pendant cette période, presque tous les produits dotés d'une API se sont vus poser la même question :

"Avez-vous le MCP ?"

Pour Apidog, ce choix semblait particulièrement naturel.

Pourquoi le MCP semblait être la réponse

Apidog avait lui-même accumulé un ensemble complet de capacités de développement d'API :

• Documentation API
• Définitions de schémas
• Serveurs de maquettes (Mock servers)
• Cas de test
• Scénarios de test
• Suites de test
• Rapports de test
• Flux de travail d'import/export
• Collaboration de branches
• Et bien d'autres

Si les agents devaient devenir le nouveau point d'entrée logiciel — une nouvelle façon pour les utilisateurs d'interagir avec les produits — alors l'exposition de ces capacités via le MCP semblait être un passage obligé.

Nous pensions que si nous pouvions regrouper nos capacités en outils MCP, les agents seraient capables de :

• Interroger la documentation API
• Créer des cas de test
• Exécuter des scénarios de test
• Importer/exporter des données de projet
• Gérer les environnements et les variables
• Collaborer entre les branches

La logique était simple : plus de capacités exposées = plus d'activation des agents.

Ce que nous avons réellement construit

Nous n'avons pas pris cela à la légère.

Apidog MCP n'était pas une simple démo avec une poignée de points d'accès écrits à la main. C'était un serveur MCP complet :

Système de session

Le client MCP initialise d'abord une session. Le serveur génère un sessionId et sauvegarde l'état de la session via Redis. Les requêtes suivantes continuent d'accéder avec le sessionId.

En d'autres termes, il ne s'agissait pas d'un appel HTTP unique, mais d'un système de session au niveau du protocole.

Catégories d'outils

La couche d'outils n'était pas non plus écrite à la main avec quelques points d'accès fixes. Nous avons divisé les outils d'Apidog en plusieurs catégories :

Cette dernière catégorie : 126 outils générés.

Chaque outil généré avait :

• Un identifiant unique
• Un chemin API spécifique
• Une méthode HTTP (GET, POST, PUT, DELETE, etc.)
• Un schéma d'entrée complet avec descriptions de champs, types et valeurs énumérées
• Une structure de retour définie

Divulgation progressive

Pour réduire la pression d'exposition des outils, nous avons également construit une couche de découverte dynamique :

L'agent pouvait :

1. Rechercher d'abord les outils de point d'accès disponibles (listOpenApiEndpoints)
2. Puis obtenir les détails OpenAPI d'un outil spécifique (getOpenApiDetails)
3. Enfin exécuter l'appel HTTP réel par l'ID de l'outil (executeOpenApi)

C'était notre tentative de divulgation progressive. Nous n'avons pas simplement exposé tous les points d'accès sous-jacents directement et explicitement. Nous espérions que les agents rechercheraient d'abord, puis obtiendraient les détails, et enfin exécuteraient.

Le mur d'outils aléatoires

Mais lors de la réalisation de tâches réelles, des problèmes sont rapidement apparus.

Considérez une simple demande d'utilisateur :

"Aidez-moi à ajouter un test pour ce point d'accès et à exécuter la vérification."

Du point de vue de l'implémentation, c'est une demande raisonnable. Apidog a les capacités de :

• Trouver des points d'accès
• Créer des cas de test
• Exécuter des scénarios de test
• Générer des rapports

Mais du point de vue de l'agent, cette simple demande déclenche en fait une série de jugements continus :

L'agent ne doit pas seulement trouver le bon outil. Il doit d'abord résoudre le problème du "quel outil utiliser", avant même de pouvoir commencer à résoudre le problème de l'utilisateur.

Du point de vue de l'implémentation, tous ces problèmes peuvent être résolus par des outils. Du point de vue de l'expérience de l'agent, ils forment un mur d'outils aléatoires.

Les quatre problèmes structurels

Grâce à des tests réels et à des retours internes, nous avons identifié quatre problèmes structurels avec l'approche MCP.

Problème 1 : Les coûts de découverte d'outils augmentent rapidement

Apidog n'est pas un produit qui peut être décrit avec seulement une douzaine de points d'accès.

Lorsque le nombre d'outils passe d'une douzaine à des dizaines ou des centaines, l'agent doit résoudre le problème de "quel outil utiliser" avant de pouvoir commencer à résoudre les problèmes de l'utilisateur.

Nous avons essayé d'écrire des flux de travail dans la description de l'outil (le champ utilisé pour exposer les outils aux agents IA). Par exemple, la description d'un outil stipulerait explicitement :

"Avant d'interroger les données d'un point d'accès, vous devez d'abord confirmer le projet via un autre outil, puis obtenir les métadonnées du projet via un troisième outil, et enfin appeler l'outil actuel."

Cette méthode fonctionne dans des ensembles d'outils à petite échelle. Mais dans un mur d'outils massif, la description elle-même entre en concurrence pour l'attention du modèle.

Plus nous écrivions de directives dans les descriptions, plus il y avait de jetons consommés — et moins il était probable que l'agent les lise et les suive réellement.

Problème 2 : Le schéma métier envahit le contexte

Chaque outil MCP n'est pas seulement un nom d'outil.

Derrière chaque outil se trouvent :

• description (ce que fait l'outil)
• input schema (paramètres, types, requis/optionnels)
• Explications de champs (structures imbriquées, contraintes)
• Valeurs énumérées (options autorisées)
• Structures de retour (format de réponse, gestion des erreurs)

Faisons une estimation prudente :

La question d'un utilisateur ne fait peut-être que 50 caractères. Mais le modèle est forcé d'introduire d'abord 50 000 jetons de descriptions d'outils — juste pour un seul serveur MCP.

Ce n'est pas théorique. Les données de l'industrie le confirment.

L'article de blog officiel de Cursor "Dynamic Context Discovery" a fourni des données de référence précieuses : en convertissant les descriptions d'outils MCP, les sessions de terminal et les longues conversations en contexte chargeable à la demande, la consommation de jetons d'exécution a été réduite de 46,9 %.

L'approche de Trae était plus directe : limiter le nombre d'outils MCP et la longueur de la description d'un seul outil :

• Limite supérieure du nombre d'outils : 40
• Limite de description d'un seul outil : 8000 caractères

En fait, lors des premiers tests internes, de nombreuses équipes ont signalé qu'Apidog MCP rencontrait des problèmes avec certains outils qui ne pouvaient pas être invoqués dans Trae. L'agent était contraint de faire des compromis en raison du contexte limité du modèle, et les outils externes étaient les premiers à être "coupés".

Ces solutions pointent toutes vers le même fait :

Les descriptions d'outils ne peuvent pas entrer infiniment dans le contexte du modèle.

Problème 3 : Les sessions de protocole alourdissent les chaînes d'exécution

Le serveur MCP d'Apidog doit gérer :

Pour un simple appel d'outil, ces coûts sont acceptables. Pour les tâches d'agent avec un grand nombre d'appels et une exploration fréquente, ces exigences de gestion d'état augmentent la complexité côté serveur et côté client.

Lors de l'implémentation d'Apidog MCP, l'équipe a consacré une énergie considérable à la résolution de problèmes et à l'adaptation aux différents clients d'agents (Cursor, Claude Code, Antigravity, Trae, etc.). Cependant, les problèmes de compatibilité des protocoles ont persisté, et le protocole MCP officiel a continué d'être corrigé avec de nouvelles versions.

Toutes les parties ont beaucoup souffert.

Problème 4 : Les outils atomiques ne peuvent pas exprimer naturellement la sémantique du produit

Dans les scénarios de test d'Apidog, il ne s'agit pas seulement d'une simple expression de tableau steps.

Un scénario de test implique :

Après avoir divisé ces éléments en plusieurs outils MCP, l'agent doit encore entreprendre le travail d'orchestration des tests lui-même.

Plus les outils sont atomiques, plus le modèle doit comprendre la sémantique interne du produit :

• Pourquoi l'importation nécessite-t-elle une relecture ?
• Pourquoi les cas internes ont-ils des marqueurs de mise à jour différents ?
• Pourquoi les assertions nécessitent-elles des comparateurs spécifiques ?
• Pourquoi l'extraction de variables a-t-elle des contraintes de type ?

C'est évidemment au-delà de la capacité du modèle.

Cela a forcé l'équipe Apidog à apporter de manière proactive des ajustements techniques d'ingénierie pour la sémantique interne du produit. Les points d'accès atomiques ont passivement ajouté une couche de conversion, juste pour s'adapter à une seule couche de répartition d'outils MCP.

Les défis d'ingénierie et les coûts de post-maintenance sont sans aucun doute ardus.

La cause fondamentale

La cause fondamentale de ces quatre problèmes est la même :

Le MCP est meilleur pour connecter les outils, mais les tâches complexes de R&D nécessitent plus qu'une simple connexion d'outils — elles nécessitent des processus d'ingénierie exécutables.

Pour les produits simples avec une douzaine d'opérations bien définies, le MCP fonctionne bien. L'agent peut raisonnablement deviner le bon outil, l'appeler et obtenir un résultat.

Pour des produits comme Apidog — avec des dizaines de modules, des centaines d'opérations, des structures imbriquées, des flux de travail cachés et une sémantique spécifique au produit — le MCP seul crée un mur d'outils aléatoires que les agents ont du mal à naviguer.

Ce que nous avons appris

Le pivot

Cette prise de conscience nous a amenés à poser une question différente :

Si le MCP n'est pas la réponse pour l'activation des agents, qu'est-ce qui l'est ?

Nous n'avons pas abandonné la valeur du MCP — il fournit des connexions standardisées, ce qui est important pour l'écosystème. Mais nous avions besoin de quelque chose qui pourrait :

• Exprimer des flux de travail, pas seulement des outils
• Guider les agents à travers des séquences
• Valider avant d'écrire
• Appliquer des contrôles de qualité d'ingénierie
• Absorber la complexité dans le système

La réponse que nous avons trouvée : CLI + SKILL.

Dans le prochain article, Pourquoi nous avons développé un tout nouveau CLI Apidog, nous explorerons le changement architectural — où la complexité est passée du contexte du modèle au système d'ingénierie, et pourquoi cela change tout pour l'activation des agents.

Points clés à retenir

• Le MCP est devenu la réponse de l'industrie à "comment les agents se connectent aux outils"
• Nous avons construit 126 outils MCP, pensant que plus d'outils = meilleure activation
• Les tâches réelles ont révélé quatre problèmes structurels : coûts de découverte, invasion du contexte, surcharge de session, sémantique du produit
• La cause fondamentale : le MCP connecte les outils, mais les tâches complexes nécessitent des processus exécutables
• Plus d'outils est un coût, pas un avantage, lorsque les descriptions d'outils consomment du contexte

Téléchargez Apidog pour concevoir, simuler, tester et documenter les API dans un seul espace de travail. En savoir plus sur Apidog CLI pour les tests d'API en ligne de commande, l'automatisation CI et les flux de travail d'agents IA.