dbt MCP — Anwendungsfälle, Installieren & Live-Demo

Warum nutzen

Hauptfunktionen

First-party — official dbt Labs MCP
Works across dbt Core (local) + dbt Cloud/Platform (hosted)
Semantic Layer integration: list_metrics, query_metrics, get_dimensions
Lineage + model health + performance out of the box

Live-Demo

In der Praxis

dbt.replay ▶ bereit

0/0

Installieren

Wählen Sie Ihren Client

~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "dbt": {
      "command": "uvx",
      "args": [
        "dbt-mcp"
      ]
    }
  }
}

Öffne Claude Desktop → Settings → Developer → Edit Config. Nach dem Speichern neu starten.

~/.cursor/mcp.json · .cursor/mcp.json

{
  "mcpServers": {
    "dbt": {
      "command": "uvx",
      "args": [
        "dbt-mcp"
      ]
    }
  }
}

Cursor nutzt das gleiche mcpServers-Schema wie Claude Desktop. Projektkonfiguration schlägt die globale.

VS Code → Cline → MCP Servers → Edit

{
  "mcpServers": {
    "dbt": {
      "command": "uvx",
      "args": [
        "dbt-mcp"
      ]
    }
  }
}

Klicken Sie auf das MCP-Servers-Symbol in der Cline-Seitenleiste, dann "Edit Configuration".

~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "dbt": {
      "command": "uvx",
      "args": [
        "dbt-mcp"
      ]
    }
  }
}

Gleiche Struktur wie Claude Desktop. Windsurf neu starten zum Übernehmen.

~/.continue/config.json

{
  "mcpServers": [
    {
      "name": "dbt",
      "command": "uvx",
      "args": [
        "dbt-mcp"
      ]
    }
  ]
}

Continue nutzt ein Array von Serverobjekten statt einer Map.

~/.config/zed/settings.json

{
  "context_servers": {
    "dbt": {
      "command": {
        "path": "uvx",
        "args": [
          "dbt-mcp"
        ]
      }
    }
  }
}

In context_servers hinzufügen. Zed lädt beim Speichern neu.

claude mcp add dbt -- uvx dbt-mcp

Einzeiler. Prüfen mit claude mcp list. Entfernen mit claude mcp remove.

Anwendungsfälle

Praxisnahe Nutzung: dbt

Diagnose why a dbt model is failing and propose a fix

👤 Analytics engineers ⏱ ~15 min intermediate

Wann einsetzen: A scheduled dbt run failed. You need to know what broke and why, without opening 5 UIs.

Voraussetzungen

dbt Cloud account + service token — dbt Cloud → Profile → API Tokens
Local dbt project checkout (if using CLI tools) — git clone your dbt repo

Ablauf

Find the failing run

List my last 10 job runs in dbt Cloud. Show which ones failed and their error summary.✓ Kopiert

→ Failed run IDs with timestamps
Drill into the failing model

For the failed run, which model failed first? Get its details (SQL, description) and its upstream lineage.✓ Kopiert

→ Failing model + dependency chain
Propose fix

Run the model locally with dbt compile. Inspect the compiled SQL for the error. Propose the minimum edit to fix.✓ Kopiert

→ Concrete SQL fix with rationale

Ergebnis: A validated fix for a broken model in under 15 minutes.

Fallstricke

Cloud run failures can be environmental (connection/credentials), not code — Before editing SQL, check if the same model runs locally via run tool — if yes, it's infra not code

Kombinieren mit: sentry · linear

Answer a business question using the dbt Semantic Layer

👤 Analytics engineers enabling self-serve ⏱ ~10 min beginner

Wann einsetzen: A stakeholder asks 'what was MRR by plan last month?' — you have metrics defined in dbt SL.

Voraussetzungen

Semantic Layer enabled on your dbt Platform project — dbt Cloud → Account Settings → Semantic Layer

Ablauf

Find the metric

List available metrics in our SL. I'm looking for MRR or monthly_revenue.✓ Kopiert

→ Matching metric found
Check dimensions

What dimensions is the MRR metric queryable by? I want to filter/group by plan and month.✓ Kopiert

→ Valid dimension list
Query and interpret

Query MRR for last month, grouped by plan. Format the result as a table and comment on biggest contributors.✓ Kopiert

→ Table + brief analysis

Ergebnis: Stakeholder gets a trustworthy, governed answer in 2 minutes; no one wrote ad-hoc SQL.

Fallstricke

Querying by an unsupported dimension returns empty without clear error — Always call get_dimensions on the metric first; don't assume

Kombinieren mit: notion

Check impact before editing a core model

👤 Analytics engineers about to touch a foundational model ⏱ ~20 min intermediate

Wann einsetzen: You're about to change dim_customers. You need to know every downstream consumer first.

Ablauf

Get lineage

Get downstream lineage for dim_customers. Include models, exposures, and any metrics.✓ Kopiert

→ Full downstream graph
Quantify impact

For each downstream model, get its model_performance and model_health — which are critical (used by exposures, run daily)?✓ Kopiert

→ Priority list of what'll break if you screw up
Plan the change

Write a change plan: what tests to add, which downstream owners to notify (check exposures), and what to monitor after deploy.✓ Kopiert

→ Rollout plan

Ergebnis: Changes to shared models ship with awareness, not blast radius surprises.

Fallstricke

Exposures only exist if you maintain them — silent downstream in BI tools isn't tracked — Combine with your BI tool's API (Looker, Tableau) to find real consumers; dbt only knows what it's told

Scaffold staging models from raw sources

👤 Analytics engineers onboarding a new source ⏱ ~30 min intermediate

Wann einsetzen: New Fivetran/source data lands. You need a stg_* model + yml for each table.

Voraussetzungen

sources.yml entries for the new data — Define sources first; agent generates staging from there

Ablauf

Generate source block

Use generate_source for database 'raw', schema 'stripe'. Write the output to models/staging/stripe/_sources.yml.✓ Kopiert

→ Source yml populated with all tables
Scaffold staging models

For each source table, call generate_staging_model. Write each to models/staging/stripe/stg_stripe__<table>.sql.✓ Kopiert

→ One .sql per source table
Add docs + tests

For each new staging model, call generate_model_yaml. Add not_null tests on primary keys. Commit.✓ Kopiert

→ Clean, tested staging layer

Ergebnis: A full staging layer in minutes; no copy-paste drift.

Fallstricke

Generated models use SELECT * which then pulls PII columns — After generation, explicitly list columns and exclude/hash any sensitive ones before merging

Kombinieren mit: git

Kombinationen

Mit anderen MCPs für 10-fache Wirkung

dbt + sentry

When a dbt model failure breaks downstream features, correlate with Sentry error spikes

Find failed dbt runs in the last 24h. For each, check Sentry for error spikes in services that depend on those models' tables.✓ Kopiert

dbt + linear

File Linear bugs for recurring dbt test failures

List dbt tests that have failed more than 3 times in the last week. For each, create a Linear bug in the Analytics team with the test details.✓ Kopiert

dbt + notion

Auto-document metrics into a Notion glossary

For every metric in our Semantic Layer, create or update a Notion page in the Metrics Glossary database with name, description, and owner.✓ Kopiert

Werkzeuge

Was dieses MCP bereitstellt

Werkzeug	Eingaben	Wann aufrufen	Kosten
list_metrics / get_dimensions / get_entities / query_metrics	metric name, dimensions, filters	Business-metric questions	SL queries billable per dbt Cloud plan
execute_sql / text_to_sql	sql or natural language	Ad hoc SQL exploration with dbt context	Warehouse credits
get_all_models / get_model_details / get_lineage	model identifiers	Discovery + impact analysis	free
get_model_health / get_model_performance	model id	SRE-style checks on the data platform	free
build / run / test / compile / parse / show / docs / list	dbt CLI args	Local dbt Core usage	warehouse compute for run/test/build
list_jobs / trigger_job_run / get_job_details / cancel_job_run / retry_job_run / list_job_runs	job/run IDs	dbt Cloud operations	1 Admin API call
generate_source / generate_staging_model / generate_model_yaml	source/model refs	Scaffolding new models	free
get_exposures / get_exposure_details	exposure name	Find downstream consumers documented as exposures	free

Kosten & Limits

Was der Betrieb kostet

API-Kontingent: dbt Cloud Admin API: depends on plan. Semantic Layer: per plan limits.
Tokens pro Aufruf: Lineage graphs + model lists can be large — paginate
Kosten in €: MCP is free; dbt Core is free; dbt Cloud/Platform is paid. Warehouse queries billed by your warehouse.
Tipp: Use discovery tools (get_model_details, get_lineage) freely — those are metadata. Be careful with execute_sql / query_metrics which hit the warehouse.

Sicherheit

Rechte, Secrets, Reichweite

Credential-Speicherung: dbt Cloud service token in env var; Core uses your profiles.yml

Datenabfluss: dbt Cloud (cloud.getdbt.com) for Cloud tools; your warehouse for SQL tools

Fehlerbehebung

Häufige Fehler und Lösungen

401 on Admin API calls

Service token expired or missing the required account. Regenerate at dbt Cloud → Account Settings → Service Tokens.

Semantic Layer tools return 'not configured'

SL is a paid feature and must be enabled per project. Check dbt Cloud → Project Settings → Semantic Layer.

CLI tools (run/build) fail with 'No profile'

Set DBT_PROFILES_DIR to a directory containing profiles.yml, or run from the project root with a local profiles.yml.

Prüfen: dbt debug

get_lineage returns empty

Manifest is stale. Run parse first to regenerate manifest.json.

Alternativen

dbt vs. andere

Alternative	Wann stattdessen	Kompromiss
SQLMesh MCP	You use SQLMesh instead of dbt	Different transformation paradigm; not a direct swap
Direct warehouse MCPs (Snowflake, BigQuery)	You only need raw SQL, not dbt metadata	Lose model/lineage/test awareness

Mehr

Ressourcen

📖 Offizielle README auf GitHub lesen

🐙 Offene Issues ansehen

🔍 Alle 400+ MCP-Server und Skills durchsuchen