Le serveur MCP dbt expose des outils répartis en quatre catégories. Les outils disponibles dépendent de votre mode de déploiement (local vs distant) et des identifiants que vous avez configurés. Cette référence les couvre tous, avec des notes sur leur utilité pratique.
Commandes CLI dbt (Serveur Local Uniquement)
Ces outils encapsulent des commandes CLI dbt. Ils s’exécutent contre votre installation et votre projet dbt locaux, ce qui signifie qu’ils ont les mêmes capacités — et les mêmes risques — que l’exécution de dbt depuis un terminal. Consultez les considérations de sécurité pour les implications en production.
| Outil | Ce qu’il fait | Quand l’utiliser |
|---|---|---|
build | Exécute les modèles, tests, snapshots et seeds dans l’ordre des dépendances | La commande tout-en-un. Utilisez-la quand vous voulez que Claude exécute tout pour une sélection. |
compile | Génère le SQL exécutable à partir des modèles sans les exécuter | Pour inspecter ce que dbt enverra réellement à l’entrepôt. Indispensable pour déboguer la logique Jinja. |
docs | Génère la documentation du projet | Pour produire ou rafraîchir les artefacts de docs dbt. |
ls | Liste les ressources du projet | Découverte. “Quels modèles existent dans la couche staging ?” |
run | Exécute les modèles pour les matérialiser dans la base de données | Pour matérialiser des modèles spécifiques. Plus ciblé que build car il saute les tests. |
test | Exécute les tests pour valider les données et l’intégrité des modèles | Pour exécuter les tests après des modifications, ou vérifier l’état actuel des tests d’un modèle. |
show | Exécute une requête contre le data warehouse | Exploration ad hoc. “Montrez-moi 10 lignes de ce modèle.” |
Exemples de Prompts pour les Outils CLI
Voici les types de questions qui déclenchent l’utilisation des outils CLI :
Compile le SQL pour stg__shopify__orders et montre-moi le résultat.L’IA appelle compile avec le sélecteur de modèle, puis présente le SQL généré. C’est indispensable pour comprendre comment les macros Jinja, les appels ref() et les blocs config se traduisent en SQL d’entrepôt réel.
Exécute les tests sur les modèles base.L’IA appelle test avec un sélecteur ciblant votre couche base. Vous voyez les résultats pass/fail sans changer de terminal.
Quelles erreurs se sont produites lors du dernier run échoué ?L’IA peut combiner ls pour trouver les modèles récents avec show pour interroger les métadonnées, selon votre configuration.
Outils de Découverte de Métadonnées
Disponibles sur les serveurs local et distant. Ces outils lisent le manifest et le catalog de votre projet dbt pour fournir des informations structurelles sur vos modèles.
| Outil | Ce qu’il fait | Quand l’utiliser |
|---|---|---|
get_mart_models | Récupère tous les modèles mart (couche de présentation) | Pour trouver ce que vos consommateurs voient. La question “Quels rapports peut-on construire ?” |
get_all_models | Récupère tous les modèles du projet | Inventaire complet. Utile pour auditer ou comprendre la portée du projet. |
get_model_details | Récupère le SQL, la description et les colonnes d’un modèle spécifique | Inspection en profondeur. “Quelles colonnes ce modèle a-t-il ? Quelle est la description ?” |
get_model_parents | Récupère les dépendances upstream d’un modèle | Pour tracer l’origine des données d’un modèle. |
get_model_children | Récupère les dépendances downstream d’un modèle | Pour comprendre l’impact. “Qu’est-ce qui casse si je modifie ce modèle ?” |
get_lineage | Récupère la lignée complète avec une profondeur configurable | Visualisation complète des dépendances. La profondeur configurable permet de voir seulement les parents/enfants immédiats ou la chaîne entière. |
get_all_sources | Récupère les tables sources avec les informations de fraîcheur | Pour vérifier quelles données externes arrivent et si elles sont à jour. |
Exemples de Prompts pour les Outils de Métadonnées
Quels modèles avons-nous dans la couche marts ?L’IA appelle get_mart_models et retourne une liste avec les descriptions. C’est le cas d’usage de découverte de données — comprendre ce qui est disponible sans fouiller dans les fichiers.
Montre-moi la lignée de mrt__sales__orders.L’IA appelle get_lineage avec un paramètre de profondeur et présente la chaîne de dépendances upstream/downstream. Cela s’articule avec les conventions de couche — vous pouvez voir comment les données circulent des sources à travers les modèles staging et intermédiaires jusqu’aux marts.
Quels modèles dépendent de base__shopify__orders ?L’IA appelle get_model_children et affiche les dépendances downstream. Indispensable pour l’analyse d’impact avant de modifier un modèle largement utilisé.
Outils Semantic Layer (Nécessite dbt Cloud)
Ces outils interrogent le Semantic Layer MetricFlow de dbt. Ils nécessitent des identifiants dbt Cloud (DBT_HOST, DBT_TOKEN, DBT_PROD_ENV_ID) que vous utilisiez le serveur local ou distant.
| Outil | Ce qu’il fait | Quand l’utiliser |
|---|---|---|
list_metrics | Récupère toutes les métriques définies | Pour découvrir quelles [[fr/metriques-as-code |
get_dimensions | Récupère les dimensions pour les métriques spécifiées | Pour comprendre selon quelles dimensions vous pouvez regrouper une métrique donnée. |
query_metrics | Interroge les métriques avec regroupement, tri et filtrage | Pour extraire réellement les valeurs de métriques. L’outil Semantic Layer le plus utilisé. |
Exemples de Prompts pour les Outils Semantic Layer
Interroge le revenu mensuel par région pour le dernier trimestre.L’IA appelle query_metrics avec la métrique de revenu, un grain temporel mensuel, une dimension de région et un filtre temporel. Le Semantic Layer gère la génération SQL en utilisant la définition de métrique gouvernée — aucun risque que l’IA calcule le revenu différemment de votre équipe finance.
Quelles dimensions sont disponibles pour la métrique customer_lifetime_value ?L’IA appelle get_dimensions et retourne la liste des dimensions selon lesquelles vous pouvez découper cette métrique. Utile quand on explore quelle analyse est possible avec vos définitions de métriques actuelles.
Outils API Admin (dbt Cloud)
Ces outils gèrent les jobs dbt Cloud. Ils nécessitent un token de service avec les permissions Job Admin.
| Outil | Ce qu’il fait | Quand l’utiliser |
|---|---|---|
list_jobs | Liste tous les jobs du projet | Pour voir quels jobs planifiés ou manuels existent. |
trigger_job_run | Démarre l’exécution d’un job | Pour déclencher un rafraîchissement. “Lance le chargement quotidien.” |
get_job_run_details | Récupère le statut et les détails d’une exécution de job | Pour vérifier si une exécution est en cours, a réussi ou a échoué. |
cancel_job_run | Annule un job en cours | Pour arrêter une exécution qui consomme des ressources ou rencontre des erreurs. |
retry_job_run | Relance un job échoué | Pour redémarrer après une erreur transitoire. |
get_job_run_error | Récupère les détails d’erreur d’une exécution échouée | Pour diagnostiquer ce qui s’est mal passé lors d’une exécution en production. |
Exemples de Prompts pour les Outils API Admin
Liste tous les jobs planifiés dans le projet.Déclenche le job de rafraîchissement quotidien.Quel est le statut du job en cours d'exécution ?Ces outils sont particulièrement utiles pour les workflows opérationnels — vérifier la santé du pipeline de production via la conversation plutôt qu’en naviguant dans l’interface dbt Cloud.
Considérations de Surcharge de Tokens
Plus de vingt définitions d’outils chargées dans la fenêtre de contexte de votre IA représentent une surcharge de tokens significative. Si vous n’avez besoin que de la découverte de métadonnées, envisagez d’utiliser les toggles de fonctionnalité (DISABLE_DBT_CLI=true, DISABLE_SEMANTIC_LAYER=true) dans votre configuration pour réduire le nombre d’outils chargés. Moins d’outils signifie plus de fenêtre de contexte disponible pour votre conversation réelle.