Labsco
MCP SERVER

dbt MCP Server

by dbt-labs

Ask business questions against dbt's Semantic Layer, then trace the answer back through lineage, model health and job runs.

Data Platform: Pipelines, Warehousing, BI & GovernanceVerified
Summary
It closes the gap between a number on a dashboard and the model that produced it.

The metric query answers the business question and the compiled SQL shows what it wrote, so the answer is checkable rather than taken on trust. From there, lineage, model health and the run error are the same conversation: 'this number looks wrong' reaches 'the upstream job failed at this step' without changing tools.

What it is

Dbt Labs' MCP server, spanning four surfaces: the Semantic Layer (metrics, dimensions, entities, queries and the compiled SQL behind them), the project graph (models, sources, macros, exposures, lineage, health and performance), the dbt platform Admin API (projects, jobs, runs, artifacts and errors), and search over docs.getdbt.com. It works against dbt Core, dbt Fusion and dbt Platform.

What you get
  • Metrics queried in business terms: list_metrics, list_saved_queries, get_dimensions, get_entities and get_dimension_values discover what exists, query_metrics answers with grouping and ordering, and get_metrics_compiled_sql returns the SQL it generated
  • The project navigated — get_all_models, get_mart_models, get_all_sources, get_all_macros, get_exposures, and get_node_details for the full schema and definition of any resource type
  • Dependencies traced in both directions with get_lineage, which returns the whole connected subgraph with type and depth filters rather than one hop
  • Whether a model can be trusted: get_model_health reports the last run, the last test status and upstream source freshness, and get_model_performance pulls execution history from past runs
  • Jobs operated from the same session — list_projects, list_jobs, get_job_details, trigger_job_run with branch and schema overrides, cancel_job_run, retry_job_run from the point of failure, and list_jobs_runs to watch
  • A failure explained quickly: get_job_run_error returns the failed step and its message instead of the whole run log, and list_job_run_artifacts shows what the run produced
  • Dbt's own documentation searched and read in place through search_product_docs and get_product_doc_pages
  • More groups available once the matching surface is configured: the dbt CLI commands (build, run, test, compile, parse, show, list, docs, clone), codegen for source and staging YAML, and column-level lineage through Fusion
  • Ten of the graph tools are marked deprecated in favour of get_node_details and get_lineage, so the real surface is smaller than the list looks
Requirements

Python with uv, a dbt project, and access to whichever surfaces you intend to use — the Semantic Layer, the Discovery API and the Admin API are configured separately, and a tool group stays out of the list when its surface is not set up. An experimental .mcpb bundle ships with each release for clients that can import one. The CLI tools run real dbt commands against your warehouse, so enable that group only for a client you trust.

Setup effort

One command — uvx dbt-mcp