@us-all/dbt-mcp
This MCP server provides read-only introspection into dbt projects and data quality monitoring, designed for LLM clients (e.g., Claude Desktop, Cursor). It parses dbt artifacts (manifest.json, run_results.json, sources.json, catalog.json) and queries custom DQ result tables (BigQuery or Postgres).
dbt Artifact Inspection
List/search models with filters (tag, schema, materialization, package); get details including columns, tests, refs, and raw/compiled SQL
List and inspect tests (generic or singular) with latest run results
List sources with freshness criteria and results, exposures (BI/ML/apps), and macros with signatures and callers
Walk DAG lineage upstream/downstream; get per-column test coverage for any model
Run History & Performance
List recent dbt invocations and per-node run results (filterable by status)
Find chronically failing tests across the last N runs; identify slowest models by execution time
Freshness & SLA Monitoring
Cross-reference source freshness criteria vs. actual results to detect stale sources
Check dbt SLA status by comparing test pass rate and freshness pass rate against configured thresholds
Data Quality (DQ) Monitoring
List recent DQ check rows filtered by dataset, status, check type, and time window
Get time-series check history; group failing checks by dataset
Trend the 4-axis DQ score (completeness, freshness, validity, anomaly-free) over time
Check Tier SLA compliance (Tier 1/2/3 targets); reconstruct tier picture from raw checks via
dq-tier-by-source
Aggregation Tools (reduce round-trips)
failed-tests-summary— dbt failures + DQ check failures in one calldq-score-snapshot— score trend + tier compliance + recent failing checksincident-context— single asset deep-dive: dbt definition + test failures + DQ checksfreshness-statusanddq-tier-by-sourcefor consolidated freshness and tier views
Discovery & Triage
search-tools— natural language tool discovery across all categories4 MCP Prompts for guided workflows: investigate failed tests, freshness degradation triage, DQ trend report, and full incident triage
Configuration & Flexibility
BigQuery and Postgres backends for DQ tables; schema presets (
genericorus-all) with per-columnDQ_COL_*overridesextractFieldsresponse projection on all tools to reduce token usageCategory-level tool toggles (
DBT_TOOLSallowlist /DBT_DISABLEdenylist)Can be paired with
@us-all/airflow-mcpfor DAG triggering and log tailing
Provides tools for interacting with a dbt project, enabling AI agents to list models, tests, sources, exposures, macros, runs, check freshness, coverage, and explore the DAG using the project's manifest, run results, and catalog.
Integrates with BigQuery to query custom data quality result tables, enabling analysis of quality checks, score trends, and tier status.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@@us-all/dbt-mcp check source freshness for tier 1 sources"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
@us-all/dbt-mcp
dbt MCP server —
manifest.json,run_results.json,sources.json,catalog.json, plus DQ result tables (BigQuery / Postgres) behind one stdio MCP. Built on@us-all/mcp-toolkit.
A read-only window into your dbt project for LLM clients. No dbt run triggering — just deep introspection, run-history analysis, source freshness, per-column test coverage, lineage walks, and (if you have a custom DQ result table) historical check trends and Tier SLA status.
For DAG triggering / run history / log tails, install the companion @us-all/airflow-mcp alongside.
27 tools across 3 categories (
dbt,quality,meta) — 21 primitive tools + 5 aggregations + 1 meta4 MCP Prompts for triage workflows
5 aggregation tools that replace 3-5 round-trips of "list / get / list"
extractFieldsresponse projection on high-volume readsRead-only by default
Hybrid backend: BigQuery (default) or Postgres for DQ result tables — both peer-imported lazily
Install
# 1. add the MCP server
pnpm add -D @us-all/dbt-mcp
# 2. add the DQ backend you actually use (only if you query custom DQ tables):
pnpm add -D @google-cloud/bigquery # OR
pnpm add -D pgRelated MCP server: dbt-mcp
Run
DBT_PROJECT_DIR=/path/to/dbt-project \
DQ_RESULTS_TABLE=my-project.data_ops.quality_checks \
npx @us-all/dbt-mcpThe server speaks MCP stdio; wire it into Claude Desktop / Cursor / any MCP client. Set MCP_TRANSPORT=http to opt in to Streamable HTTP transport (Bearer auth, /health endpoint).
Categories
Category | Tools | Purpose |
| 15 + 3 aggregations | Parse |
| 6 + 2 aggregations | Query |
| 1 (always on) |
|
Toggle with DBT_TOOLS=dbt (allowlist) or DBT_DISABLE=quality (denylist).
Tools at a glance
dbt (15 + 3)
dbt-list-models, dbt-get-model, dbt-list-tests, dbt-get-test, dbt-list-sources, dbt-get-source, dbt-list-exposures, dbt-list-macros, dbt-get-macro, dbt-list-runs, dbt-get-run-results, dbt-failed-tests, dbt-slow-models, dbt-coverage, dbt-graph, freshness-status, incident-context, dbt-sla-status
quality (6 + 2)
dq-list-checks, dq-get-check-history, dq-failed-checks-by-dataset, dq-score-trend, dq-tier-status, dq-tier-by-source, failed-tests-summary, dq-score-snapshot
Prompts
Prompt | Use when |
| "What's broken in the last 24h?" |
| "Are any sources stale?" (Tier 1 focus optional) |
| "Give me a stakeholder-friendly DQ trend report" |
| "Triage <model | source>" — bundles all signals |
Environment variables
Env | Required | Notes |
| yes | dbt project root (where |
| no | Defaults to |
| no | Optional dir for archived |
| no |
|
| no | FQN of the checks table; required only for checks-based quality tools |
| no | FQN of the score-daily table; required for score-only tools |
| no | For BigQuery backend (ADC fallback supported) |
| no | Explicit BQ project (otherwise inferred from ADC) |
| no | When |
| no |
|
| no | Per-column overrides on top of |
| no | Tier 1 SLA threshold for |
| no | Optional YAML path with |
| no | Reserved for future write tools (none currently) |
| no | Category toggles |
DQ result-table schema flavors
The quality category supports two schema presets via DQ_SCHEMA:
DQ_SCHEMA=generic (default)
Columns assumed on DQ_RESULTS_TABLE: run_at, check_name, check_type, dataset, table_name, status, severity, failure_count, message.
Columns assumed on DQ_SCORE_TABLE: score_date, scope, tier, completeness_pct, freshness_pct, validity_pct, anomaly_free_pct, overall_score.
dq-tier-status rolls up by Tier 1/2/3 against the per-scope rows.
DQ_SCHEMA=us-all
Real schema used at us-all (Postgres data_ops database):
quality_checks: run_date, check_type, dimension, source, target_name, status, metric_value, threshold, details (JSONB).
quality_score_daily: run_date, completeness_pct, freshness_pct, validity_pct, anomaly_free_pct, overall_score, total_checks, failed_checks.
In this flavor quality_score_daily is one row per day (no per-scope rollup, no tier column). dq-tier-status falls back to comparing the day's overall_score against DQ_TIER1_TARGET_PCT (default 99.5).
dq-get-check-history requires checkName formatted as '<check_type>:<target_name>' since us-all has no native check_name column.
Per-column overrides — DQ_COL_*
If your DQ tables don't match either preset, layer per-column overrides on top of DQ_SCHEMA. Any DQ_COL_* env var, when set, replaces the preset value for that single column. Unset vars keep the preset default.
Overrides are validated as simple SQL identifiers to avoid injecting raw SQL through environment variables. Table names in DQ_RESULTS_TABLE / DQ_SCORE_TABLE are also validated and quoted for the configured backend.
Env var | Logical concept | Generic preset | us-all preset |
| timestamp/date on the checks table |
|
|
| check type / dimension family |
|
|
| pass/fail/warn/error |
|
|
| dataset / source / schema |
|
|
| table or target name |
|
|
| severity / dimension |
|
|
| numeric failure count / metric |
|
|
| free-text or JSON message |
|
|
| natural identifier of the check |
| (none) |
| date column on the score table |
|
|
| scope/tenant column on score table |
| (none) |
| tier column on score table |
| (none) |
For the three nullable columns (DQ_COL_CHECK_NAME, DQ_COL_SCOPE, DQ_COL_TIER), set the value to none / null / - to declare "no native column":
Without
check_name→ the tools synthesize one fromcheck_type || ':' || table_name.dq-get-check-historythen expectscheckNameformatted as'<check_type>:<table_name>'.Without
scope→dq-score-trend'sscopefilter is ignored (with a caveat) anddq-tier-statusswitches to the single-overall_scorepath that compares againstDQ_TIER1_TARGET_PCT.Without
tier→ same single-overall_scorefallback.
Example — generic preset against a Postgres schema where columns happen to be named differently:
DQ_SCHEMA=generic
DQ_COL_RUN_AT=checked_at
DQ_COL_DATASET=schema_name
DQ_COL_TABLE_NAME=tbl
DQ_COL_FAILURE_COUNT=fail_n
DQ_COL_CHECK_NAME=none # synthesize from check_type+tbl
DQ_COL_SCOPE=none # no per-team rollup
DQ_COL_TIER=none # use DQ_TIER1_TARGET_PCT insteadSLA config (optional) — DBT_SLA_CONFIG_PATH
Set DBT_SLA_CONFIG_PATH to a YAML file to surface project-defined tier targets and DBT SLAs to the quality tools. Schema (extra keys ignored):
dbt_sla:
test_pass_pct: 99.0 # consumed by dbt-sla-status (test pass rate threshold)
freshness_pass_pct: 99.5 # consumed by dbt-sla-status (source freshness pass rate threshold)
tier_sla:
1: 99.5 # tier-1 overall_score / per-source pass-rate target
2: 99.0
3: 95.0When set, the tier_sla map drives:
dq-tier-status— per-tier rollup compares each row'soverall_scoreagainst the matching target. Without this file, hardcoded{1: 99.5, 2: 99.0, 3: 95.0}is used.dq-tier-by-source— per-source pass-rate is compared to the target for that source's tier (resolved from dbt sources.ymlmeta.tier).dq-tier-statusno-tier-column path (us-all preset /DQ_COL_TIER=none) — usestier_sla.1as the single target.DQ_TIER1_TARGET_PCTenv still works as a fallback when no SLA file is set.
The dbt_sla block drives:
dbt-sla-status— computes test pass rate from latestrun_results.jsonand freshness pass rate fromsources.json, then compares each axis againstdbt_sla.test_pass_pct/dbt_sla.freshness_pass_pct. ReturnspassPct,target,meetingper axis plus caveats when fields or artifacts are missing.
The file is mtime-cached; edits between tool calls are picked up automatically.
Per-tier rollup from quality_checks — dq-tier-by-source
For schemas where quality_score_daily has only one row per day (no per-scope/tier breakdown), dq-tier-by-source reconstructs a per-tier picture from the raw quality_checks rows. Two modes:
mode: "source" (default) — group by source/dataset column
Use when each row of quality_checks represents a check on a source group and the dataset/source column carries the dbt source-group name directly.
Builds a
source_name -> tiermap from the dbt manifest'ssources.<source>.<table>.meta.tier(first table's tier per source group).Groups
quality_checksrows by the dataset/source column and computes pass rate per source over a date orsinceHourswindow.Looks up each source's tier and target (from SLA config or defaults), reports meeting / missing per tier.
mode: "table" — group by table_name column
Use when the dataset/source column is a category (bq / dbt / airflow) and the actual dbt source-table identifier lives in the table_name / target_name column as <source_group>.<table>. Common in checks tables that consolidate signals from heterogeneous backends.
Builds a
<source_group>.<table> -> tiermap from the manifest using each source entry'ssource_name + name + meta.tier— picks up table-level tier overrides naturally.Groups
quality_checksrows by thetable_namecolumn. Pre-filter viasourceFilter(e.g.sourceFilter: "bq") when only some categories produce parseable target names.Each rollup key is parsed as
<source_group>.<table>; rows without a.or whose key is not in the manifest land incaveats[].
Untiered rows (no manifest meta.tier) and unparseable rows always appear in caveats[] so you can tier them or accept the gap.
Tested-against schemas
dbt manifest schema v11 / v12 — the current top version. dbt 1.7 emits v11; dbt 1.8 through 1.12 all emit v12 (the schema evolves additively in-place). Newer/unknown versions still parse, but a
caveatsline will flag them.
Companion server
For Airflow DAG operations (list, runs, task instances, log tail, trigger, clear), install @us-all/airflow-mcp alongside this server.
Build
pnpm install
pnpm run build # tsc → dist/
pnpm test # vitest
pnpm run smoke # spawns dist/index.js, calls initialize + tools/list (set env first)License
MIT — see LICENSE.
Available Tools
27 toolsdbt-coverageA
Per-column test coverage for a dbt model (which columns have tests, table-level tests, coverage %)
Inputs: name, uniqueId, extractFields.
dbt-failed-testsB
Find tests that failed across the last N runs, grouped and ordered by chronic failure count
Inputs: recentRuns, extractFields.
dbt-get-macroA
Get a dbt macro: signature, raw SQL, and reverse-lookup of nodes that call it
Inputs: name, uniqueId, extractFields.
dbt-get-modelA
Get a single dbt model: refs, sources, columns (with catalog types if available), attached tests, raw/compiled SQL
Inputs: name, uniqueId, extractFields, includeCompiledSql.
dbt-get-run-resultsB
Get per-node results from a specific dbt invocation (or the latest run if invocationId omitted)
Inputs: limit, status, invocationId, extractFields.
dbt-get-sourceA
Get a single dbt source: freshness criteria, columns, latest freshness result from sources.json
Inputs: uniqueId, tableName, sourceName, extractFields.
dbt-get-testA
Get a single dbt test: definition, parameters, attached models, latest run result
Inputs: uniqueId (required), extractFields.
dbt-graphB
Walk dbt parent_map / child_map to return upstream and downstream nodes (model/source/test) up to a given depth
Inputs: name, uniqueId, extractFields, upstreamDepth, +1 more.
dbt-list-exposuresA
List dbt exposures (downstream BI/ML/application consumers declared in YAML)
Inputs: limit, search, exposureType, extractFields.
dbt-list-macrosA
List dbt macros from manifest.json with package / name filters
Inputs: limit, search, package, extractFields.
dbt-list-modelsA
List dbt models from manifest.json with filters (package, tag, materialized, schema, name search)
Inputs: tag, limit, schema, search, +3 more.
dbt-list-runsC
List recent dbt invocations from run_results.json files in target/ and DBT_RUN_HISTORY_DIR
Inputs: limit, extractFields.
dbt-list-sourcesC
List dbt sources from manifest.json with optional source-group / name filters
Inputs: limit, search, sourceName, extractFields.
dbt-list-testsC
List dbt tests (generic or singular) optionally filtered to a specific model
Inputs: limit, search, testKind, attachedTo, +1 more.
dbt-sla-statusB
Compare latest dbt run test pass rate and source freshness pass rate against DBT_SLA_CONFIG_PATH thresholds (dbt_sla.test_pass_pct / freshness_pass_pct). Returns per-axis passPct/target/meeting plus caveats when SLA fields or artifacts are missing.
Inputs: extractFields.
dbt-slow-modelsB
Top N slowest models in a dbt run by execution_time, with bytes_processed when available
Inputs: topN, invocationId, extractFields.
dq-failed-checks-by-datasetB
Group failing checks by dataset across a recent window with the latest 5 failures per dataset
Inputs: topN, sinceHours, extractFields.
dq-get-check-historyC
Time-series of one check_name's status across the last N days
Inputs: checkName (required), days, limit, extractFields.
dq-list-checksA
List recent rows from DQ_RESULTS_TABLE filtered by dataset / status / type / time window
Inputs: type, limit, status, dataset, +2 more.
dq-score-snapshotA
Aggregated 4-axis score trend + today's Tier compliance + most recent failing checks. Combines dq-score-trend + dq-tier-status + dq-list-checks(fail).
Inputs: days, extractFields, includeFailing.
dq-score-trendB
Time-series of the 4-axis DQ score (completeness / freshness / validity / anomaly_free) plus overall_score from DQ_SCORE_TABLE
Inputs: days, scope, extractFields.
dq-tier-by-sourceA
Per-tier rollup computed from quality_checks grouped by source. Reads source-to-tier mapping from dbt sources.yml meta.tier and tier targets from DBT_SLA_CONFIG_PATH (falls back to defaults). Reports per-source pass rate, meeting/missing per tier, and untiered sources as caveats.
Inputs: date, mode, sinceHours, sourceFilter, +1 more.
dq-tier-statusA
Compare today's overall_score per scope against Tier SLA targets (defaults Tier 1 99.5 / 2 99.0 / 3 95.0; override via DBT_SLA_CONFIG_PATH yaml or DQ_TIER1_TARGET_PCT) and report meeting vs missing counts
Inputs: date, extractFields, fallbackMaxDays.
failed-tests-summaryA
Aggregated 24h-ish view: dbt failed tests + DQ checks failures grouped by dataset + most recent failing rows. Replaces 3+ tool calls (dbt-failed-tests + dq-failed-checks-by-dataset + dq-list-checks).
Inputs: recentRuns, sinceHours, extractFields.
freshness-statusB
Cross-reference dbt source freshness criteria with sources.json results in a single 'is anything stale right now?' answer.
Inputs: failingOnly, extractFields.
incident-contextA
Single asset deep-dive: dbt definition + recent test failures + DQ checks for the dataset. Designed to anchor an LLM-driven incident triage.
Inputs: modelName, sourceFqn, sinceHours, extractFields.
search-toolsA
Discover available dbt MCP tools by natural language query across dbt / quality / meta categories.
Inputs: query (required), limit, category.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 27 tools
Most tools have distinct purposes, but composite tools like `failed-tests-summary` overlap with `dbt-failed-tests` and `dq-failed-checks-by-dataset`, and `incident-context` aggregates multiple individual tools, potentially causing confusion about which to use.
Tools follow a consistent prefix pattern (`dbt-` and `dq-`) but there are deviations like `dbt-graph` instead of `dbt-get-graph`, and four tools without any prefix (`failed-tests-summary`, `freshness-status`, `incident-context`, `search-tools`), mixing naming conventions.
With 27 tools covering dbt core operations, data quality, and incident triage, the count is slightly high but well-justified for the broad scope, avoiding the extremes of overwhelming or insufficient coverage.
The tool set covers essential dbt monitoring and data quality workflows (listing, details, failures, SLAs, scores), but lacks write operations and some administrative functions, though that seems intentional for a read-only analysis server.
Maintenance
Related MCP Connectors
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAI-driven MCP server that audits, profiles, detects schema drift, and auto-generates documentation for dbt projects, enabling natural language interaction with your dbt project's health.103MIT
- AlicenseNot gradedqualityDmaintenanceMCP server that provides tools to interact with dbt, including dbt Core, Cloud CLI, Semantic Layer, and Discovery API.Apache 2.0
- AlicenseNot gradedqualityDmaintenanceA production-ready MCP server that provides comprehensive dbt project quality assessment for any GitHub repository, enabling AI agents to analyze dbt models, check metadata coverage, and map data lineage.8MIT
- AlicenseNot gradedqualityDmaintenanceMCP server providing read-only Snowflake metadata tools (schemas, tables, queries, lineage) for agentic data pipeline generation, enabling natural-language-to-pipeline workflows with dbt, Airflow, and Great Expectations.1MIT