Votre serveur MCP n'a pas besoin de 40 outils

Les démos MCP montrent souvent tout en même temps. Elles présentent chaque endpoint et chaque table de base de données. Elles prétendent que l'agent peut tout appeler.

Cela semble puissant pendant dix minutes. Puis le modèle échoue. Il appelle le mauvais outil. Il transmet des arguments sous la mauvaise structure. Il demande un graphique à partir d'un endpoint de recherche. Il réessaie une action destructrice.

Le problème n'est pas MCP. Le problème est de traiter MCP comme un adaptateur magique pour votre backend.

Un serveur MCP n'est pas seulement votre API rendue accessible aux agents. C'est une interface produit pour un utilisateur très littéral et très distrait. Cet utilisateur est un modèle de langage.

Si vous donnez 40 outils similaires à un modèle, vous ne lui donnez pas de la puissance. Vous lui donnez 40 façons d'être presque correct.

Arrêtez de reproduire vos routes d'API. Les humains peuvent lire la documentation et comprendre le contexte. Les modèles font du pattern-matching sur les noms et les descriptions.

Construisez votre couche MCP autour de l'intention de l'utilisateur.

Au lieu de reproduire chaque route, regroupez-les par limites claires :

  • Un outil pour les résumés de marché
  • Un outil pour les calendriers de publication
  • Un outil pour des instantanés de données spécifiques
  • Un outil pour les indicateurs historiques

Une route d'API dit : Si vous envoyez cette requête, le serveur répondra. Un outil MCP devrait dire : Utilisez-moi pour cette tâche précise, avec ces entrées exactes, et attendez-vous à ce résultat spécifique.

De bonnes descriptions d'outils sont une logique de routage, pas du texte marketing.

Mauvais : name: get_data description: Gets data from the API.

Meilleur : name: lookup_release_calendar description: Return scheduled economic events for one currency and date range. Use this before answering questions about upcoming macro events.

Suivez ces règles pour obtenir de meilleurs agents :

  1. Utilisez des noms ennuyeux. Les développeurs aiment les noms compacts comme fetch ou query. Les modèles ont besoin de noms spécifiques comme search_docs ou check_deployment_status. Les noms ambigus coûtent cher.

  2. Contrôlez la structure de la réponse. Ne renvoyez pas d'objets imbriqués géants. Renvoyez la structure la plus simple possible qui permet d'accomplir la tâche. Si le modèle voit trop de données, il utilisera le mauvais champ ou hallucinera des détails.

  3. Concevez pour l'échec. La qualité de production provient de la manière dont vous gérez les erreurs. Ne renvoyez pas simplement une erreur 500 ou un tableau vide. Dites au modèle pourquoi il a échoué. Si aucun enregistrement ne correspond, dites au modèle de suggérer une plage de dates plus large à l'utilisateur.

Le meilleur outil d'agent n'est pas le plus puissant. C'est celui que le modèle ne peut pas mal interpréter.

Source: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1

Communauté d'apprentissage optionnelle: https://t.me/GyaanSetuAi