
Dbt
io.github.us-allPublished by GitHub account us-allv1.0.7Updated Oct 24, 2026
dbt MCP — manifest/run_results/sources/catalog parsing + DQ result tables (BigQuery/Postgres)
Overview
A read-only MCP server that lets an assistant introspect a dbt project's artifacts and query data-quality result tables in BigQuery or Postgres.
- What you can do
- Browse and inspect dbt models, tests, sources, exposures and macros from the project's manifest and catalog files, with lineage graph walks and per-column test coverage checks. Review run history and run results, list failed tests, find slow models, and check source freshness. Query data-quality result tables for check history, failed checks by dataset, score trends, tier status and per-source tier rollups. Compute dbt SLA status against test and freshness pass-rate targets from an optional YAML config. Discover tools by natural language and use built-in prompts for failed-test, freshness, trend and incident triage workflows.
- When to use it
- Useful when an assistant needs to answer questions about a dbt project's structure, test coverage, run history or source freshness, or to summarize data-quality trends and SLA status from existing quality result tables. It is read-only and does not trigger dbt runs.
- Requirements
- Runs locally over stdio as an npm package (npx @us-all/dbt-mcp). Requires DBT_PROJECT_DIR pointing at the dbt project root; DBT_TARGET_DIR and DBT_RUN_HISTORY_DIR are optional. Quality tools need a DQ backend: BigQuery (default, with GOOGLE_APPLICATION_CREDENTIALS or ADC and optional BQ_PROJECT_ID) or Postgres (DQ_BACKEND=postgres plus PG_CONNECTION_STRING), and the DQ_RESULTS_TABLE / DQ_SCORE_TABLE names. Optional DBT_SLA_CONFIG_PATH YAML for SLA targets.
Installation
In SourceWeft
- Open Dbt in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
@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 meta - 4 MCP Prompts for triage workflows
- 5 aggregation tools that replace 3-5 round-trips of "list / get / list"
extractFieldsresponse projection on high-volume reads- Read-only by default
- Hybrid backend: BigQuery (default) or Postgres for DQ result tables — both peer-imported lazily
Install
Run
The 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
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
Environment variables
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.
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:
SLA 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):
When 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
License
MIT — see LICENSE.
Source: README.md at commit 3af1107
Tools
0Version history
1- v1.0.7LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts