Ce qu’un serveur MCP contient réellement
Trois choses, et il est utile de les distinguer parce qu’on les confond souvent.
Les outils. Des fonctions que le modèle peut appeler, chacune avec un nom, une description, un schéma de paramètres et un retour. C’est la partie qui compte.
Les ressources. Des contenus que le modèle peut lire sans déclencher d’action : un document, une fiche, un extrait de référentiel. Utile, mais rarement décisif.
Les invites préenregistrées. Des modèles de requête que le client peut proposer à l’utilisateur. Confort d’interface, pas architecture.
Un serveur qui n’a que des outils bien décrits fonctionne. Un serveur qui a les trois mais des outils flous ne fonctionne pas. C’est là que se joue le résultat.
La description d’un outil est le vrai code
C’est le point que la plupart des équipes découvrent trop tard. Le modèle ne voit pas votre implémentation : il voit un nom, une phrase et un schéma. S’il se trompe d’outil, ce n’est presque jamais sa faute, c’est que deux descriptions se ressemblent.
Trois règles que nous appliquons systématiquement :
Une intention métier, un outil. Pas une fonction par point d’entrée de l’API. « Trouver les factures impayées d’un client » est un outil ; « GET /invoices avec neuf paramètres facultatifs » n’en est pas un, parce qu’il oblige le modèle à deviner la combinaison utile.
La description dit quand ne pas l’utiliser. Une phrase du type « ne pas utiliser pour les avoirs, voir tel autre outil » supprime la moitié des erreurs de sélection. C’est contre-intuitif et très efficace.
Le schéma refuse plutôt qu’il ne devine. Un paramètre obligatoire non fourni doit produire une erreur explicite que le modèle peut lire et corriger, pas une valeur par défaut silencieuse qui donne un résultat faux mais plausible.
Le nombre d’outils est une contrainte, pas un détail
Au-delà d’une vingtaine ou d’une trentaine d’outils, la sélection se dégrade : chaque description supplémentaire dilue les autres. Deux réponses possibles.
La première est de regrouper : remonter d’un niveau d’abstraction pour que dix outils couvrent ce que cent points d’entrée exposaient. C’est presque toujours la bonne réponse, et elle demande de comprendre le métier.
La seconde est de sélectionner avant d’appeler : un premier étage choisit les quelques outils pertinents pour la question, et seuls ceux-là sont présentés au modèle. C’est ce qu’il faut quand le périmètre est réellement large, comme sur un progiciel de gestion complet.
Sécurité : trois décisions à prendre avant la première ligne
Le périmètre est fermé par défaut. Le serveur n’expose que ce que vous avez décidé d’ouvrir, outil par outil. Un serveur qui expose « la base » n’est pas un serveur MCP, c’est une porte.
Les droits sont ceux de l’utilisateur, pas ceux du serveur. Si le serveur interroge tout avec un compte privilégié, un utilisateur obtient par l’agent ce qu’il ne voit pas dans le logiciel. C’est une fuite d’information sans faille technique, et elle est invisible en démonstration.
L’injection par le contenu se traite côté serveur. Un document, un ticket ou un champ libre peut contenir des instructions que le modèle prend pour des consignes. Aucune consigne système ne règle ce problème de façon fiable. Ce qui le règle : des écritures qui passent par des fonctions contrôlées, une validation humaine sur ce qui n’est pas annulable, et la journalisation de chaque appel avec ses paramètres. Le raisonnement complet est sur MCP.
Ce qu’un serveur en production nous a appris
Nous opérons des serveurs MCP devant des logiciels métier de clients, dont un couvrant plusieurs dizaines d’outils sur un progiciel de gestion. Sur l’agent de reporting d’OOTI, un ERP du bâtiment, deux mesures résument tout ce qui précède :
- 92 % de précision d’appel d’outil, c’est-à-dire la bonne fonction avec les bons paramètres. Ce chiffre a bougé quand nous avons réécrit les descriptions, pas quand nous avons changé de modèle.
- Moins de 0,10 $ par interaction, parce que l’agent appelle deux ou trois outils précis au lieu de charger un contexte massif.
L’enseignement est toujours le même : changer de modèle prend une journée, écrire le contrat des outils prend le projet. Le SDK que nous utilisons pour construire ces serveurs est publié en source ouverte sous le nom rakam_systems.
Quand construire un serveur, et quand s’en passer
S’en passer pour un premier projet, sur un seul logiciel, avec un seul agent. L’appel direct de vos API va plus vite, et la description des outils sera réutilisable ensuite de toute façon.
Le construire dès qu’il y a plusieurs consommateurs : plusieurs modèles, un client de bureau et un agent serveur, ou plusieurs équipes qui veulent brancher leurs propres assistants. À partir de là, on décrit les outils une fois au lieu d’une fois par intégration, et c’est ce qui rend le coût raisonnable.