Créer et Déployer son Propre Serveur MCP

Mise à jour du 2 novembre 2026 — Le Chat devient Vibe. Depuis le 28 mai 2026, Le Chat s’appelle Vibe (toujours sur chat.mistral.ai) : un seul agent pour le travail et le code, avec vos conversations, réglages et abonnements repris. L’ancienne expérience Le Chat reste accessible dans le mode Chat ; dans le mode Work, les agents sont devenus des skills (invoquées avec @), les mémoires la base de connaissances et la recherche approfondie la skill Deep Research. Les offres s’appellent désormais Mistral Free, Pro, Team et Enterprise. Cette leçon emploie désormais le nom Vibe ; certains menus décrits ici ont pu changer de nom ou de place.

De l’idée au serveur en production

Vous savez utiliser les connecteurs existants et ajouter un connecteur personnalisé. Il reste à franchir la dernière marche : écrire votre propre serveur MCP et le déployer pour l’exploiter dans Vibe. Nous suivons ici le chemin complet, du premier fichier Python sur votre machine jusqu’à l’hébergement en production, en passant par les choix de conception qui feront la différence entre un serveur utilisable et un serveur que le modèle n’appellera jamais correctement.

Créer un serveur MCP en local

La bibliothèque FastMCP (pip install fastmcp, version 4 en novembre 2026), un framework indépendant du SDK officiel mcp, réduit le serveur à quelques décorateurs :

from fastmcp import FastMCP

mcp = FastMCP("Mon Serveur")

@mcp.tool()
def greet(name: str) -> str:
    """Salue une personne par son nom.

    Args:
        name: Le prénom de la personne à saluer.

    Returns:
        Un message de salutation personnalisé.
    """
    return f"Bonjour {name} ! Bienvenue sur notre plateforme."

Tout se joue dans ces quelques lignes. Le décorateur @mcp.tool() enregistre la fonction comme outil MCP. La docstring devient la description que le modèle voit pour décider s’il doit appeler l’outil — elle n’est donc pas un commentaire à destination de vos collègues, mais un élément fonctionnel. Le typage des paramètres (name: str) et du retour (-> str) informe le modèle sur les types attendus, et le nom de la fonction doit être clair et descriptif. L’alternative officielle est le SDK MCP d’Anthropic, disponible en Python et en TypeScript : il offre plus de contrôle au prix d’une configuration un peu plus lourde.

Puisque le modèle ne voit que la description textuelle de votre outil, écrivez-la comme une notice d’emploi complète :

@mcp.tool()
def search_products(
    query: str,
    category: str = "all",
    max_results: int = 10
) -> str:
    """Recherche des produits dans le catalogue.

    Utilisez cet outil quand l'utilisateur cherche un produit
    par nom, référence ou catégorie.

    Args:
        query: Termes de recherche (nom du produit, référence, mots-clés).
        category: Catégorie de filtre. Valeurs possibles : 'all',
                  'electronics', 'clothing', 'food'. Défaut : 'all'.
        max_results: Nombre maximum de résultats à retourner (1-50).

    Returns:
        Liste de produits avec nom, prix, disponibilité et référence.
    """

Remarquez ce que cette docstring apporte et que la précédente n’avait pas : la condition d’usage, les valeurs possibles de category et les bornes de max_results. Deux autres règles complètent l’exercice. Les noms doivent être explicites — préférez search_products à search, create_invoice à create, get_user_orders à get_data. Et les retours doivent être lisibles : renvoyez des textes compréhensibles plutôt que des identifiants bruts, faute de quoi le modèle ne pourra pas s’en servir pour formuler une réponse naturelle.

Tester en local

Lancez d’abord le serveur, qui démarre sur un port local, par défaut localhost:8000 :

python server.py

Exposez-le ensuite pour que Vibe puisse l’atteindre :

ngrok http 8000

ngrok fournit une URL publique, par exemple https://abc123.ngrok.io, que vous utiliserez comme URL de connecteur dans Vibe — en pensant à ajouter /mcp à la fin pour obtenir l’endpoint complet. Avant d’aller dans Vibe, validez le serveur avec le MCP Inspector :

npx @modelcontextprotocol/inspector

Connectez-vous à votre serveur local, listez les outils, testez-les individuellement et vérifiez les retours. Vous saurez ainsi si un éventuel problème vient de votre code ou de la façon dont le modèle interprète vos descriptions.

Options de déploiement

Une fois le serveur au point, l’hébergement dépend surtout de vos contraintes. Hugging Face Spaces est l’option gratuite recommandée par l’équipe Mistral AI : ce sont des machines virtuelles qui hébergent des applications web, entièrement gratuites tant que vous n’avez pas besoin de GPU. Vous pouvez y monter votre serveur MCP avec FastAPI et déployer plusieurs serveurs sur le même Space, chacun avec son propre endpoint — /api1/mcp, /api2/mcp — que Vibe ajoutera comme connecteurs distincts. Avantage supplémentaire, rien ne vous empêche d’ajouter au Space un frontend pour visualiser l’activité de vos serveurs.

Prefect Horizon (anciennement FastMCP Cloud), la plateforme de l’équipe de FastMCP, importe directement un dépôt GitHub contenant un serveur FastMCP : vous choisissez le dépôt sur horizon.prefect.io, la plateforme le construit et publie une URL authentifiée ; une offre gratuite existe pour les projets personnels. Pour les serveurs légers, sans dépendances lourdes, Cloudflare Workers offre un déploiement edge rapide et peu coûteux. Enfin, les fournisseurs classiques restent parfaitement viables pour les équipes déjà outillées : AWS (Lambda, ECS), Google Cloud (Cloud Run, Cloud Functions) ou Azure (Functions, Container Apps).

Serveurs multi-outils ou mono-outil

Un réflexe fréquent consiste à découper très finement les outils. L’expérience va plutôt dans l’autre sens : un hackathon MCP organisé par Mistral a montré que les équipes les plus performantes concevaient des outils de haut niveau, correspondant à des workflows complets. Elles exposaient book_restaurant au lieu de list_restaurants + check_availability + make_reservation, ou deploy_application au lieu de build + test + push + deploy. Le modèle a moins d’occasions de se tromper d’enchaînement, et la latence cumulée diminue d’autant.

La granularité garde toutefois son intérêt dans trois situations : lorsque vous créez un serveur MCP générique utilisé par différentes équipes, lorsque les étapes du workflow peuvent servir indépendamment les unes des autres, et lorsque vous avez besoin de flexibilité dans l’ordre des opérations.

Gestion des variables d’environnement

Vos serveurs auront souvent besoin de clés API, de credentials de base de données ou d’autres secrets. Stockez-les systématiquement dans des variables d’environnement, jamais dans le code. Gardez surtout à l’esprit qu’un serveur MCP public, sans authentification, fait consommer vos clés API par toute personne qui l’utilise : protégez-le avec un token ou OAuth dès qu’il appelle un service facturé. Sur Hugging Face Spaces, les Secrets du Space sont prévus exactement pour cela.

Points clés à retenir

• FastMCP est le moyen le plus simple de créer un serveur MCP en Python
• Soignez les descriptions, les noms et le typage de vos outils
• Testez d’abord en local avec ngrok et le MCP Inspector avant de déployer
• Hugging Face Spaces offre un hébergement gratuit idéal pour les serveurs MCP
• Préférez les outils de type workflow aux outils trop granulaires
• Protégez vos secrets et envisagez une authentification pour vos serveurs