Nous Construisons les Serveurs MCP de la Mauvaise Façon

Quand la plupart des développeurs construisent leur premier serveur MCP, ils font quelque chose de prévisible : ils prennent leur API REST et encapsulent chaque endpoint en outil MCP. GET /users devient get_users. Le mapping est 1:1, mécanique et faux.

C'est faux parce que les APIs REST sont conçues pour des développeurs qui lisent la documentation et enchaînent les appels dans leur tête. Les LLM ne fonctionnent pas ainsi. Ils travaillent avec des descriptions d'outils, pas de la doc.

Quand vous mappez aveuglément REST vers MCP, vous forcez le LLM à reconstruire le modèle mental que votre doc aurait donné à un développeur. Parfois ça marche. Souvent non. Et quand ça ne marche pas, vous blâmez le LLM au lieu du design de l'outil.

Le changement fondamental : les endpoints REST modélisent des ressources. Les outils MCP devraient modéliser des tâches.

Une API REST a GET /users/{id}, GET /users/{id}/orders, GET /orders/{id}/items. Trois endpoints, trois appels, trois réponses à assembler.

Un serveur MCP devrait avoir un outil get_user_order_summary qui renvoie tout en un appel. Le LLM a demandé « qu'a commandé cet utilisateur ? » — donnez-lui la réponse, pas trois pièces de puzzle.

Ça semble faux pour les puristes. Ça viole la normalisation. Mais le consommateur n'est pas un développeur — c'est un LLM qui performe mieux avec moins d'appels plus complets.

Dans une API REST, le chemin et la méthode HTTP portent de l'information sémantique. GET /users est évident.

Les LLM ne parsent pas les patterns d'URL. Ils lisent les descriptions d'outils. Votre description est la seule documentation qui compte. Si elle est vague, le LLM utilisera mal l'outil.

Écrivez les descriptions comme si vous expliquiez l'outil à un collègue très littéral sans contexte. Dites exactement ce que l'outil fait, ce qu'il retourne, quand l'utiliser et quand NE PAS l'utiliser.

La plupart des serveurs MCP ont des descriptions qui auraient un D en écriture technique. C'est l'amélioration la plus impactante que vous puissiez faire.

Un pattern que je vois constamment : un serveur MCP avec search_documents, find_documents et query_documents. Trois outils qui font presque la même chose.

Pour un développeur humain, les différences sont évidentes. Pour un LLM, ce sont trois outils avec des descriptions similaires. Il devine mal environ 40% du temps.

Le chevauchement d'outils est la source numéro un de problèmes de fiabilité MCP. La solution est la déduplication impitoyable. Si deux outils peuvent être fusionnés, fusionnez-les. Ajoutez des paramètres au lieu d'ajouter des outils.

Moins d'outils plus capables battent toujours beaucoup d'outils spécialisés.

La méta-leçon est simple : les outils MCP ont un consommateur différent des APIs REST.

Testez vos outils avec de vrais LLM. Pas seulement « l'outil s'exécute-t-il correctement ? » — mais « le LLM choisit-il le bon outil, passe-t-il les bons paramètres ? »

Surveillez comment les LLM utilisent vraiment vos outils en production. Vous trouverez des patterns surprenants.

Les meilleurs serveurs MCP ne sont pas ceux avec le plus d'outils. Ce sont ceux où le LLM obtient la bonne réponse du premier coup, à chaque fois.