Le serveur MCP dbt existe en deux modes de déploiement — local et distant — avec des capacités fondamentalement différentes.
Serveur Local
Le serveur local s’exécute sur votre machine. Il génère un processus dbt en parallèle de votre installation existante et communique via le transport stdio. Trois éléments sont nécessaires : le gestionnaire de paquets uv, une installation dbt (Core, Fusion Engine ou Cloud CLI fonctionnent tous), et un répertoire de projet contenant dbt_project.yml.
Ce que vous obtenez :
- Accès CLI complet.
run,build,test,compile,docs,ls,show— chaque commande dbt que vous exécuteriez dans un terminal, accessible via la conversation. - Découverte des métadonnées. Parcourir les modèles, inspecter les colonnes, tracer la lignée upstream et downstream. Aucun compte cloud n’est nécessaire pour cela.
- Requêtes Semantic Layer (optionnel). Si vous ajoutez des identifiants dbt Cloud, le serveur local peut également interroger les métriques via MetricFlow. Mais c’est additionnel — tout le reste fonctionne sans Cloud.
- Gestion des jobs (optionnel). Même principe : ajoutez les identifiants Cloud et vous pouvez lister, déclencher, annuler et relancer des jobs dbt Cloud.
Le serveur local est un surensemble. Il commence par CLI + métadonnées, et s’enrichit de fonctionnalités Cloud optionnelles.
Aucun compte dbt Cloud n’est requis pour la fonctionnalité de base. C’est le détail important qui se perd dans la documentation de dbt Labs. Si vous exécutez dbt Core sur votre ordinateur portable contre un entrepôt, le serveur local fonctionne parfaitement. Vous n’aurez simplement pas le Semantic Layer ni la gestion des jobs.
Serveur Distant
Le serveur distant est hébergé par dbt Labs. Aucune installation, pas de uv, pas de dbt local. Vous configurez votre client MCP pour vous connecter à l’endpoint de dbt Cloud, vous authentifiez avec un token de service, et vous êtes connecté.
Ce que vous obtenez :
- Métadonnées en lecture seule. Détails des modèles, lignée, fraîcheur des sources — les mêmes outils de découverte que le serveur local.
- Requêtes Semantic Layer. Métriques, dimensions, filtrage — les fonctionnalités MetricFlow.
Ce que vous n’obtenez pas :
- Pas de commandes CLI. Pas de
run,build,test,compile. Le serveur distant ne peut pas exécuter dbt contre votre entrepôt. C’est purement une interface de métadonnées et de métriques.
La Décision
Les data engineers veulent généralement le serveur local, qui fournit l’accès CLI — la possibilité de compiler du SQL, d’exécuter des tests et de construire des modèles spécifiques via la conversation. Sans accès CLI, le serveur est limité à la lecture des métadonnées.
Le serveur distant convient aux analystes et parties prenantes qui ont besoin d’interroger le Semantic Layer sans toucher à la codebase — obtenir des réponses à partir de définitions de métriques gouvernées sans accès CLI.
| Serveur Local | Serveur Distant | |
|---|---|---|
| Installation | Nécessite uv, dbt, répertoire de projet | Aucune |
| dbt Cloud requis | Non (optionnel pour le Semantic Layer) | Oui |
| Commandes CLI | Accès complet | Aucune |
| Découverte de métadonnées | Oui | Oui |
| Semantic Layer | Avec identifiants Cloud | Oui |
| Gestion des jobs | Avec identifiants Cloud | Non |
| Idéal pour | Data engineers, analytics engineers | Analystes, parties prenantes |
Les Deux à la Fois
Rien ne vous empêche d’exécuter les deux. Un data engineer pourrait utiliser le serveur local pour le développement — compiler du SQL, exécuter des tests, déboguer des modèles — tandis que son organisation déploie également le serveur distant pour les analystes qui ont besoin d’accéder au Semantic Layer. Les serveurs ne rentrent pas en conflit car ils servent des objectifs différents via des mécanismes de transport différents.
Le serveur local utilise le transport stdio (lancé comme sous-processus), tandis que le serveur distant utilise le transport HTTP (se connectant à l’endpoint hébergé de dbt Cloud). Ils coexistent naturellement comme entrées séparées dans la configuration de votre client MCP.
La Mise en Garde Expérimentale
dbt Labs marque les deux serveurs comme expérimentaux. La surface des outils a changé entre les versions, et le canal #tools-dbt-mcp dans le Slack de la communauté dbt est l’endroit où les changements cassants sont annoncés. C’est un facteur à prendre en compte dans la quantité de choses que vous construisez par-dessus le serveur — gardez vos workflows adaptables plutôt que fortement couplés à des noms d’outils ou des comportements spécifiques.