Configurer des serveurs MCP dans Vibe

Qu’est-ce que MCP ?

Le Model Context Protocol (MCP) est un standard ouvert qui permet aux agents IA de communiquer avec des serveurs d’outils externes. Au lieu de coder chaque intégration en dur, MCP fournit un protocole unifié : le serveur expose des outils, l’agent les découvre et les utilise automatiquement. Vous n’écrivez donc pas de code de liaison, vous déclarez une adresse ou une commande, et les outils apparaissent dans la session suivante.

Vibe intègre nativement le support MCP, ce qui signifie que vous pouvez étendre ses capacités bien au-delà des outils de base — lire une page web, interroger une base de données, appeler une API interne à votre entreprise.

Les deux types de transport

La question à trancher avant toute configuration est celle du transport, c’est-à-dire du canal par lequel Vibe parle au serveur.

Avec le transport HTTP, le serveur MCP tourne comme un service web classique, et Vibe envoie des requêtes pour découvrir et appeler les outils :

[[mcp_servers]]
name = "mon_serveur_http"
transport = "http"
url = "http://localhost:8000"
headers = { "Authorization" = "Bearer mon_token_ici" }

Ce mode est adapté quand le serveur MCP tourne en continu — un service de base de données, une API interne, un outil web partagé par toute l’équipe.

Avec le transport STDIO, le serveur est un programme local que Vibe lance lui-même et avec lequel il communique via stdin/stdout :

[[mcp_servers]]
name = "fetch_server"
transport = "stdio"
command = "uvx"
args = ["mcp-server-fetch"]

C’est le mode le plus simple à configurer, car Vibe gère le cycle de vie du serveur : il le lance au début de la session et l’arrête à la fin. Rien à démarrer manuellement, rien à surveiller.

Il existe enfin une variante du transport HTTP, streamable-http, destinée aux connexions longue durée avec streaming :

[[mcp_servers]]
name = "mon_serveur_stream"
transport = "streamable-http"
url = "http://localhost:9000/mcp"

Exemple concret : ajouter la récupération web

L’un des serveurs MCP les plus utiles est mcp-server-fetch, qui permet à Vibe de lire le contenu de pages web. Trois lignes de configuration suffisent :

# ~/.vibe/config.toml

[[mcp_servers]]
name = "fetch"
transport = "stdio"
command = "uvx"
args = ["mcp-server-fetch"]

Le changement dans votre usage quotidien est immédiat. Vous pouvez désormais formuler une demande qui suppose une lecture externe :

Lis la documentation de FastAPI sur fastapi.tiangolo.com et résume-moi les endpoints de sécurité

L’agent appellera automatiquement l’outil fetch du serveur MCP pour récupérer la page, puis analysera son contenu. Vous n’avez ni ouvert de navigateur, ni collé un extrait de documentation dans le terminal.

Filtrage des outils MCP

Cette facilité a une contrepartie. Chaque serveur ajouté apporte son lot d’outils, et avec trois ou quatre serveurs actifs le catalogue devient encombrant. Le filtrage permet de ne garder que ce qui est pertinent :

# Activer uniquement les outils d'un serveur spécifique
enabled_tools = ["fetch_*"]

# Désactiver tous les outils MCP sauf ceux explicitement activés
disabled_tools = ["mcp_*"]

Le filtrage par wildcards sert deux objectifs à la fois. Il renforce la sécurité, en réduisant ce que l’agent est autorisé à faire, et il évite de surcharger le contexte du modèle : une liste d’outils trop longue consomme du contexte utile et dégrade la qualité des décisions de l’agent.

Configuration avancée avec authentification

Les serveurs MCP d’entreprise exigent presque toujours une authentification. Vibe accepte des en-têtes personnalisés, et surtout des références à des variables d’environnement avec la syntaxe ${VARIABLE} :

[[mcp_servers]]
name = "api_interne"
transport = "http"
url = "https://mcp.votre-entreprise.com"
headers = { "Authorization" = "Bearer ${MCP_API_TOKEN}" }

L’intérêt est direct : le fichier config.toml peut être versionné et partagé avec l’équipe sans contenir le moindre secret en dur, chaque développeur fournissant son propre jeton via son environnement.

Serveurs MCP populaires

Plusieurs serveurs prêts à l’emploi couvrent les besoins les plus fréquents, et tous se déclarent de la même façon dans config.toml. mcp-server-fetch gère la récupération de pages web et d’APIs ; mcp-server-filesystem élargit les opérations sur les fichiers au-delà des outils natifs ; mcp-server-git apporte une intégration Git avancée avec diff, blame et log ; mcp-server-sqlite et mcp-server-postgres ouvrent l’interrogation de bases SQLite et PostgreSQL. Un agent capable de lire le schéma d’une base et le code qui l’utilise repère des incohérences qu’aucune lecture de fichiers seule ne révélerait.

En cours de session, vous pouvez vérifier quels serveurs sont connectés et quels outils sont disponibles ; l’agent vous indique par ailleurs les outils qu’il utilise dans ses réponses, ce qui reste le meilleur moyen de contrôler qu’un serveur fonctionne réellement.

Sécurité des serveurs MCP

Un serveur MCP s’exécute avec vos droits et voit ce que vous lui donnez : n’ajoutez que des serveurs de confiance, car un serveur malveillant pourrait exposer des données de votre codebase. Limitez ensuite les permissions avec enabled_tools plutôt que d’accorder l’accès complet par défaut.

Deux réflexes complètent cette hygiène. Vérifiez vos headers : aucun token sensible ne doit figurer en clair dans config.toml, la syntaxe ${VARIABLE} existe précisément pour cela. Et pour les outils locaux, préférez le transport STDIO, plus sûr qu’un serveur HTTP exposé sur le réseau, ne serait-ce que parce qu’il n’ouvre aucun port.

Points clés à retenir

• MCP permet d’ajouter des outils externes à Vibe via un protocole standardisé
• Deux transports principaux : HTTP (serveur permanent) et STDIO (processus local)
• Le filtrage d’outils (enabled_tools, disabled_tools) contrôle ce que l’agent peut utiliser
• Les variables d’environnement dans les headers protègent les secrets
• N’ajoutez que des serveurs MCP de confiance et limitez les permissions