D'une API REST a un Serveur MCP en 10 Minutes

Si vous avez une API REST, vous avez 90% d'un serveur MCP. C'est ce que personne ne vous dit.

Vos endpoints sont vos outils. Vos schemas de requete sont vos schemas d'entree. Vos formats de reponse sont vos types de sortie. La correspondance est presque honteusement directe.

POST /users/create ? C'est un outil create_user. GET /orders/:id ? C'est get_order. Les types de parametres, les regles de validation, les formes d'erreur — vous avez deja tout ecrit. Probablement deux fois, si on compte la spec OpenAPI.

La seule chose qui manque, c'est la couche de traduction. Et — c'est la partie qui va vous pieger — de bonnes descriptions. Pas "description : cree un utilisateur." Des descriptions avec lesquelles un LLM peut raisonner. Cette distinction compte plus que vous ne le pensez.

Les outils MCP correspondent presque 1:1 aux endpoints REST. Ce n'est pas un hasard. Les deux repondent fondamentalement a la meme question : que peut faire ce service, et comment lui demander de le faire ?

Les traductions de schemas sont mecaniques. JSON Schema en entree, JSON Schema en sortie. Les champs requis restent requis. Les enums restent des enums. Les objets imbriques restent imbriques. En plissant les yeux, une definition d'outil MCP ressemble a une operation OpenAPI avec une meilleure ergonomie.

On pourrait automatiser la conversion. Nous l'avons automatisee. Le mapping structurel est un probleme resolu. Vous n'avez pas besoin d'y penser.

Ce a quoi vous devez penser, c'est tout ce que la structure ne capture pas. Les contrats implicites. Les dependances d'ordre. Le savoir "n'appelez pas cet endpoint avant d'appeler celui-la" qui vit dans les tetes de votre equipe et nulle part ailleurs. C'est ca le vrai travail de traduction.

C'est la que la plupart des migrations echouent. Et ce n'est pas ou vous l'attendriez.

Vous copiez les noms des endpoints, generez les schemas depuis votre spec OpenAPI, et vous deployez. Tout a l'air genial. Les definitions d'outils sont propres. Les types sont corrects. Vous vous sentez productif.

Puis le LLM appelle create_user alors qu'il devrait appeler update_user. Pourquoi ? Parce que les deux descriptions disent "gere les donnees utilisateur." Vous les avez ecrites pour un developpeur qui lirait le chemin URL et comprendrait la difference. Un LLM ne lit pas les chemins URL. Il lit les descriptions.

Vos descriptions doivent etre sans ambiguite, specifiques, et ecrites pour un lecteur qui n'a jamais vu votre systeme et ne le verra jamais. "Cree un nouveau compte utilisateur avec l'email et le mot de passe fournis. Renvoie l'objet utilisateur cree avec un ID genere. Echoue si l'email est deja enregistre." Ca, c'est une description avec laquelle un LLM peut travailler.

C'est le vrai travail difficile de la migration. Pas la plomberie — le nommage.

Voici le raccourci. Pointez SmeltSec vers votre spec OpenAPI ou votre depot GitHub. C'est tout. C'est le point de depart.

Il lit vos endpoints, deduit l'intention depuis la structure de vos routes et la documentation existante, genere des outils MCP avec des schemas corrects, et ecrit des descriptions que les LLMs peuvent reellement interpreter. Puis il lance une analyse de securite pour detecter les vecteurs d'empoisonnement d'outils et les schemas d'entree trop permissifs.

Les 10 minutes du titre sont genereux. La plupart des depots prennent moins de 60 secondes. Le goulot d'etranglement n'est pas la generation — c'est vous qui relisez le resultat et decidez si les descriptions capturent fidelement ce que fait chaque outil.

Vous pourriez faire tout ca a la main. Vous y passeriez un week-end. Vous reussiriez les schemas et rateriez les descriptions, parce qu'ecrire de bonnes descriptions est une competence que la plupart des ingenieurs backend n'ont jamais eu besoin de developper. C'est le genre de travail ennuyeux et critique que l'outillage devrait gerer.

Ce qui surprend dans la conversion vers MCP, ce n'est pas la conversion. C'est ce qui se passe apres.

Votre API a soudain de nouveaux consommateurs que vous n'attendiez pas. Des agents IA commencent a appeler vos outils de manieres que vous n'avez jamais testees. Ils composent vos outils avec d'autres outils de services completement sans rapport — un outil de calendrier appelle votre outil de paiement qui appelle un outil de notification, le tout orchestre par un LLM qui a decouvert le workflow tout seul.

Vous ne construisez plus une API. Vous contribuez a un ecosysteme. Vos outils deviennent des briques dans des systemes que vous n'avez pas concus et que vous ne pouvez pas predire.

C'est inconfortable si vous etes habitue a controler toute la surface d'integration. C'est grisant si vous realisez ce que ca signifie : votre service vient de devenir utile de manieres que vous n'auriez pas pu imaginer, pour des utilisateurs que vous ne rencontrerez jamais, resolvant des problemes dont vous ignoriez l'existence.

C'est la vraie raison de faire le changement. Pas parce que MCP est plus recent ou plus tendance. Parce que ca fait compter votre travail dans un monde bien plus grand.