Intégrer un Serveur Custom dans Vibe

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.

Connecter votre serveur MCP à Vibe

Votre serveur est déployé et répond en HTTPS sur une adresse stable. Reste l’étape qui donne son sens à tout le travail précédent : le rendre utilisable en conversation par ceux à qui il est destiné, y compris ceux qui n’ouvriront jamais un terminal. Vibe accepte n’importe quel serveur MCP conforme sous forme de connecteur custom. Cette leçon couvre l’ajout du connecteur, le déroulé des appels en conversation, puis le diagnostic des pannes — car la première tentative échoue souvent.

Ajouter le connecteur

Ouvrez Vibe sur chat.mistral.ai et rejoignez l’onglet Connectors dans la barre latérale. Vous y trouverez deux sections distinctes : les connecteurs featured, préconfigurés par Mistral (GitHub, Notion, et les autres), et vos propres connecteurs custom, initialement vide. Cliquez sur Add Custom Connector et renseignez les champs :

1. Name : un nom descriptif (ex: “Gestionnaire de Tâches”)
2. Server URL : l’URL complète de votre endpoint MCP (ex: https://mon-serveur.com/tasks/mcp)
3. Description : ce que fait votre serveur (optionnel mais recommandé)

Vient ensuite le choix de l’authentification, entre No authentication pour un serveur public, Token si vous collez votre API token, et OAuth 2.0 pour un flux de consentement complet. Un clic sur Connect déclenche la découverte : si tout va bien, Vibe affiche la liste des tools trouvés sur votre serveur, avec le nom et la description de chacun. C’est votre premier vrai retour sur la qualité de vos docstrings — vous les lisez ici exactement comme le modèle les recevra.

Ce qui se passe en conversation

Une fois connecté, votre serveur apparaît dans la section Tools de la barre de chat, signalé par une icône indiquant la disponibilité d’outils externes. L’utilisateur formule sa demande en langage naturel, et le modèle traduit :

Utilisateur : Crée une tâche haute priorité pour préparer la démo MCP

Le Chat : [Appelle create_task avec les arguments suivants]
  - title: "Préparer la démo MCP"
  - priority: "high"

  → Voulez-vous autoriser cet appel d'outil ?

Utilisateur : [Autorise]

Le Chat : La tâche "Préparer la démo MCP" a été créée avec succès
en haute priorité. Son identifiant est abc123.

Cette demande de confirmation est le comportement par défaut, et vous pouvez y répondre ponctuellement ou basculer un tool en autorisation permanente. Résistez à la tentation pour tout ce qui n’est pas un serveur vous appartenant. La confirmation ne protège pas seulement contre les bugs : elle est votre unique rempart contre les injections de prompts, où des instructions dissimulées dans les données retournées par un tool détournent le modèle vers des appels que personne n’a demandés. Voir défiler les arguments avant validation est ce qui permet de repérer l’anomalie.

Quand ça ne marche pas

Le message « Impossible de se connecter » recouvre presque toujours l’une de ces quatre causes : l’URL n’est pas joignable depuis l’extérieur, le protocole n’est pas HTTPS — Vibe l’exige —, le serveur n’est tout simplement pas démarré, ou les CORS ne sont pas configurés alors que Vibe émet ses requêtes depuis un navigateur. La commande suivante tranche entre les deux premières hypothèses en quelques secondes :

# Tester l'accessibilité
curl -X POST https://votre-url/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc": "2.0", "method": "tools/list", "id": 1}'

Si la connexion aboutit mais qu’aucun tool ne s’affiche, remontez la chaîne côté serveur : vérifiez que le décorateur @app.tool() est bien présent sur chaque fonction, qu’aucune docstring ne manque, et que le serveur MCP est monté sur la route que vous croyez. Passez par MCP Inspector avant toute autre investigation.

Le cas le plus déroutant est celui où tout fonctionne, mais où le modèle appelle le mauvais tool ou n’en appelle aucun. Le problème n’est alors pas technique : le modèle choisit d’après les descriptions, et si deux tools se ressemblent ou si l’un d’eux reste vague, il tranche mal. Trois leviers, dans cet ordre — rendre la description plus spécifique en explicitant le cas d’usage, renommer le tool pour lever l’ambiguïté, et réduire le nombre de tools actifs simultanément. Enfin, si un tool retourne une erreur, consultez les logs du serveur, rejouez l’appel manuellement dans l’inspector, et vérifiez que les variables d’environnement sont définies et que le token ou les scopes OAuth donnent bien les permissions attendues.

Le MCP Inspector, à utiliser avant Vibe

L’inspector teste vos tools sans passer par le modèle, ce qui isole la moitié des variables du problème :

npx @modelcontextprotocol/inspector

Il ouvre une interface web dans laquelle vous vous connectez à votre serveur distant par son URL, listez tous les tools avec leurs descriptions et leurs paramètres, exécutez un tool avec les arguments de votre choix, et lisez la réponse brute du serveur. Prenez l’habitude de faire cette vérification systématiquement avant d’ajouter un serveur dans Vibe, car elle vous donne un diagnostic immédiat : si un tool répond correctement dans l’inspector mais échoue dans Vibe, le serveur est hors de cause et la faute revient à la description ou au prompt.

Vivre avec plusieurs serveurs

Une fois plusieurs connecteurs installés, la discipline devient le principal facteur de qualité. Vibe permet de toggler chaque connecteur : ne laissez actifs que les tools nécessaires à la tâche du moment, car un modèle noyé sous cinquante outils choisit moins bien et répond moins vite. Cette hygiène s’appuie sur le découpage par domaine vu à la leçon 10 — un serveur pour la gestion de projet, un pour le monitoring, un pour les outils internes — puisqu’il suffit alors d’activer celui qui correspond à la conversation en cours.

Adaptez enfin vos prompts aux capacités réellement exposées :

# Bon : reflète les capacités des tools
"Crée une tâche haute priorité intitulée 'Préparer la démo'"

# Mauvais : trop vague, le modèle ne sait pas quel tool utiliser
"Gère mon projet"

Un dernier point mérite d’être connu avant de concevoir vos serveurs : les connecteurs MCP configurés dans Vibe restent disponibles sur l’application mobile. Vos outils internes deviennent donc accessibles depuis un téléphone, ce qui ouvre des usages en situation de terrain auxquels on ne pense pas en développant sur un poste fixe.

Points clés à retenir

• L’ajout d’un connecteur custom dans Vibe se fait en 3 étapes : nom, URL, auth
• Gardez la confirmation manuelle des appels de tools activée par sécurité
• Utilisez le MCP Inspector pour tester et débugger avant d’intégrer dans Vibe
• Améliorez les descriptions des tools si le modèle ne les utilise pas correctement
• Ne gardez actifs que les tools nécessaires à la tâche en cours
• Vos serveurs MCP sont aussi accessibles sur mobile