Wrapper REST ou serveur MCP conçu pour l'agent : pourquoi les wrappers échouent
Un outil par endpoint est la façon la plus rapide de sortir un serveur MCP, et la plus fiable d'en faire un que personne ne garde. Pourquoi, et quoi faire à la place.
La façon la plus rapide de sortir un serveur MCP est de générer un outil par endpoint de ton API. Ton API a soixante endpoints, ton serveur a soixante outils, c'est fait en une journée.
C'est aussi la façon la plus fiable de produire un serveur que personne ne garde installé.
Pourquoi ça échoue
Une API REST et un serveur MCP n'ont pas le même utilisateur.
Une API sert un développeur. Il lit la documentation, il comprend le modèle de données, il enchaîne trois appels dans le bon ordre parce qu'il a conçu le parcours à l'avance. La granularité fine est une qualité : elle lui donne du contrôle.
Un serveur MCP sert un modèle. Il choisit au moment de l'appel, à partir de noms et de descriptions, dans un contexte partagé avec d'autres serveurs. La granularité fine devient un coût : chaque outil supplémentaire est une occasion de se tromper.
Quatre symptômes signent un wrapper :
Des outils qui ne veulent rien dire seuls. patch_resource_v2 a du sens dans une doc, pas dans une liste de choix.
Des enchaînements obligatoires non dits. Il faut appeler A puis B, et rien ne le dit au modèle, qui appelle B directement et échoue.
Des réponses conçues pour être parsées. Un JSON de deux cents champs dont l'agent n'utilise qu'un. Ça consomme du contexte et ça noie l'information.
Aucune distinction de risque. Lire et supprimer se ressemblent, donc rien ne déclenche de confirmation.
Ce que fait un serveur conçu pour l'agent
Il part des intentions, pas des ressources. Tu listes ce que les utilisateurs veulent obtenir, en leurs mots, et tu construis les outils à partir de cette liste. Souvent, dix intentions couvrent 90 % des usages d'une API de soixante endpoints.
Il absorbe les enchaînements. Si publier suppose de valider, de générer et d'activer, l'outil s'appelle publish et fait les trois. L'agent n'a pas à connaître ta plomberie.
Il renvoie ce qui sert à la décision suivante. Une réponse courte, lisible, avec le handle nécessaire pour continuer. Pas ton objet complet.
Il déclare son risque. Lecture seule ou destructeur, annoté, pour que le client puisse demander une confirmation.
Il échoue de manière instructive. Un message d'erreur qui dit ce qui manque permet au modèle de se corriger seul. C'est la différence entre un outil qui marche une fois sur deux et un outil qui marche.
L'objection légitime
« Si je n'expose pas tout, mes utilisateurs avancés seront bloqués. »
C'est vrai, et ça se traite autrement : un ou deux outils génériques bien bornés couvrent la longue traîne, pendant que les dix outils d'intention couvrent le quotidien. Tu ne sacrifies pas la couverture, tu la hiérarchises.
Ce qui ne marche pas, c'est de mettre les soixante au même niveau et d'espérer que le modèle trie.
La méthode en trois étapes
- Liste vingt demandes réelles, formulées par des utilisateurs, dans leur vocabulaire
- Regroupe-les en intentions. Tu obtiens généralement entre huit et quinze groupes
- Un outil par intention, avec les enchaînements absorbés et les paramètres qui portent la variation
Ensuite seulement, tu regardes ton API pour voir comment implémenter. Dans cet ordre. L'inverse produit un wrapper.
Le test qui tranche
Connecte ton serveur à côté de deux autres, prends tes vingt demandes, et compte les fois où le bon outil est choisi du premier coup.
Un wrapper tourne autour de 60 à 70 %. Un serveur conçu pour l'agent dépasse 90 %. Cet écart, c'est toute la différence entre un produit qu'on désinstalle et un produit qu'on garde.
FAQ
Faut-il jeter le wrapper existant ?
Rarement. On garde l'implémentation et on refait la surface : regroupement, nommage, descriptions, annotations, réponses. C'est un chantier de quelques semaines, pas une réécriture.
Comment justifier ça en interne ?
Avec le taux de sélection mesuré. C'est un chiffre, il se compare avant et après, et il parle à une direction technique.
Et si mon API est le produit ?
Alors tu as deux produits avec deux utilisateurs différents. C'est plus de travail, mais c'est la réalité de la situation.
Refaire la surface plutôt que le serveur
L'audit à 950 € mesure le taux de sélection de ton serveur actuel et chiffre la refonte de la surface d'outils. La construction complète va de 4 500 à 7 500 € selon le périmètre.
Intéressé ? Parler de mon serveur MCP →
Lectures liées
Un serveur MCP à faire auditer ?
Cinq minutes pour le décrire. Je réponds sous 24 heures ouvrées avec un premier diagnostic écrit et gratuit.
Faire auditer mon serveur MCP