Ce qu'il faut réellement pour exposer une API REST en serveur MCP avec Python : le SDK, un outil fonctionnel, et la partie qui décide si un agent s'en sert correctement.
Un serveur qui fonctionne, c'est là où l'effort s'arrête et où la vente commence. Pointez MCP Showcase dessus et obtenez un playground en direct que vos clients peuvent essayer, avec une documentation générée pour chaque outil.
Indiqué ci-dessus, avec le fait qu'il soit officiellement maintenu ou communautaire, ce qui compte plus dans certains langages que dans d'autres.
Commencez par un seul outil, pas par toute votre API. Les définitions d'outils sont envoyées au modèle à chaque requête, et la justesse de la sélection baisse à mesure que la liste s'allonge.
Passez l'URL déployée dans le MCP Inspector pour confirmer que le handshake aboutit et que les outils apparaissent comme prévu.
pip install mcp — modelcontextprotocol/python-sdk (FastMCP),
officiellement maintenu.
FastMCP déduit le schéma d'entrée d'un outil de vos annotations de type et sa description de la docstring. C'est le chemin le plus rapide vers un serveur fonctionnel et la raison pour laquelle la plupart des exemples MCP sont en Python, mais cela signifie aussi que ce que lit le modèle, c'est votre docstring. Une docstring vague donne un outil que l'agent choisit mal, et rien dans vos tests ne le détectera.
Un serveur MCP est une fine couche au-dessus de code que vous avez déjà. Chaque outil a besoin de trois choses : un nom, une description disant ce qu'il fait et quand le choisir, et un schéma d'entrée. Le SDK pour Python s'occupe du protocole ; ce que vous écrivez, c'est la correspondance entre ces arguments et votre appel HTTP existant.
Commencez par un endpoint plutôt que par toute votre API. Les définitions d'outils sont renvoyées au modèle à chaque requête : chacune est donc un coût de contexte permanent, et la capacité du modèle à choisir correctement baisse quand la liste s'allonge. Huit outils bien décrits valent mieux que quatre-vingts.
Quel que soit le langage, ce sont les descriptions qui décident du comportement de l'agent. Elles sont lues par le modèle, pas par vos collègues, et un outil décrit en trois mots est appelé au hasard. Vous pouvez vérifier les vôtres avec l'analyseur de schémas MCP, et voir ce que la liste coûte par requête avec le calculateur de tokens.
Une fois qu'il tourne, il reste que personne ne peut dire ce qu'il fait. Un prospect ne peut pas lire votre code Python et n'installera pas un client pour le découvrir. MCP Showcase pointe sur la même URL et produit un playground en direct avec une documentation générée pour chaque outil, pour qu'évaluer votre serveur prenne un clic.