Utiliser des serveurs MCP dans Vibe

De la configuration à l’usage réel

La leçon 8 vous a montré comment déclarer des serveurs MCP dans config.toml. Le fichier est écrit, les serveurs répondent — reste la question qui compte au quotidien : qu’est-ce que cela change concrètement à vos sessions de travail ? C’est l’objet de cette leçon.

Donner accès au web

Le serveur le plus rentable à installer en premier est mcp-server-fetch, parce qu’il lève la limite la plus gênante d’un agent local : l’ignorance de tout ce qui n’est pas sur votre disque. Une fois configuré, Vibe lit n’importe quelle page.

Lis la documentation de l'API Stripe sur les webhooks et résume-moi les étapes d'implémentation

Récupère le contenu de cette issue GitHub : https://github.com/org/repo/issues/42

Vérifie la dernière version disponible de la bibliothèque fastapi sur pypi.org

Notez qu’à aucun moment vous n’avez indiqué quel outil employer. L’agent appelle l’outil fetch de lui-même dès qu’il détecte qu’une URL ou une référence web est nécessaire ; c’est le contexte de votre demande qui décide, pas une instruction explicite de votre part.

Interroger vos données

Le même principe s’applique à une base de données, via un serveur MCP SQLite ou PostgreSQL. La déclaration reste courte :

# Configuration dans config.toml
[[mcp_servers]]
name = "db_locale"
transport = "stdio"
command = "uvx"
args = ["mcp-server-sqlite", "--db-path", "./data/app.db"]

En session, vous posez alors des questions métier, pas du SQL : « Montre-moi les 10 derniers utilisateurs inscrits avec leur date de création », ou « Combien de commandes ont été passées ce mois-ci ? Groupe-les par statut ». L’agent rédige la requête, l’exécute et vous rend un résultat lisible. Le SQL redevient un détail d’implémentation.

Composer plusieurs serveurs

La vraie puissance de MCP apparaît quand deux serveurs travaillent dans le même échange. Avec fetch et SQLite actifs simultanément, une demande comme celle-ci mobilise les deux :

Compare les données de notre base avec la documentation officielle de l'API. 
Y a-t-il des champs manquants dans notre schéma ?

Vibe lit la documentation par le serveur fetch, inspecte votre schéma par le serveur SQLite, puis croise les deux. Deux workflows courants reposent sur cette composition. La veille technologique d’abord :

1. Récupère les dernières releases de React sur GitHub
2. Compare avec la version dans notre package.json
3. Si une mise à jour majeure est disponible, résume les breaking changes

L’agent enchaîne l’appel au serveur fetch pour GitHub, la lecture locale du package.json et l’analyse, sans que vous ayez à découper la demande. L’audit de dépendances suit la même logique, avec une itération en plus :

Pour chaque dépendance dans @package.json, vérifie sur npm s'il existe 
des vulnérabilités connues et dresse un rapport

Vibe parcourt les dépendances une à une, sollicite le serveur fetch pour chacune et compile les résultats en un rapport unique.

Savoir ce qui est disponible, et diagnostiquer les pannes

En cours de session, vous n’êtes pas obligé de deviner quels outils MCP sont actifs. Chaque fois que Vibe en utilise un, il indique clairement le serveur et l’outil invoqués dans sa sortie, consultable avec Ctrl+O. Vous pouvez aussi poser la question directement : « Quels outils le serveur MCP “fetch” met-il à disposition ? ».

Quand un serveur ne répond plus ou renvoie une erreur, Vibe vous en informe explicitement. Quatre causes couvrent l’essentiel des cas.

Pour les transports STDIO, la question du démarrage ne se pose pas : Vibe gère lui-même le cycle de vie du serveur et, si le processus plante, il tente de le relancer.

Garder des sessions rapides

Chaque serveur MCP actif ajoute ses outils au contexte de l’agent, et cela ne se voit pas jusqu’au jour où vous en avez huit. Les deux effets sont mécaniques : le temps de réponse s’allonge, parce que le modèle doit arbitrer entre davantage d’options, et le coût par requête augmente, puisque toutes ces définitions d’outils occupent des tokens dans le contexte facturable. La règle est donc simple : n’activez que les serveurs utiles à la session en cours.

Quand un serveur ne vous intéresse que pour une partie de ce qu’il expose, le filtrage vaut mieux que la désactivation complète :

# N'utiliser que l'outil fetch du serveur, pas les autres
enabled_tools = ["fetch_fetch"]

Enfin, préférez STDIO pour tout ce qui tourne en local. Vibe lance et arrête ces serveurs automatiquement : vous n’avez aucun service à maintenir en arrière-plan, ni à redémarrer après un reboot.

Points clés à retenir

• Les serveurs MCP étendent Vibe avec des capacités web, base de données et plus
• L’agent choisit automatiquement quel outil MCP utiliser selon le contexte
• Plusieurs serveurs MCP peuvent être combinés dans un même workflow
• Limitez le nombre de serveurs actifs pour maintenir les performances
• Le filtrage d’outils permet un contrôle fin des capacités disponibles