dbt MCP Server

Der dbt MCP Server verbindet KI-Assistenten wie Claude Code oder Cursor mit Ihren dbt-Projekten und den Daten, die dbt verwaltet. dbt ist das gängige Werkzeug, um Transformationen im Data Warehouse als Code zu pflegen; der MCP-Server gibt einem Assistenten Kontext darüber, welche Modelle es gibt, wie sie zusammenhängen, welche Metriken definiert sind und ob Daten aktuell sind. Statt Modellnamen und Abhängigkeiten selbst herauszusuchen, fragen Sie in natürlicher Sprache, und der Assistent ruft die passenden Werkzeuge auf. Das Projekt liegt in der GitHub-Organisation dbt-labs, steht unter der Apache-2.0-Lizenz, hat aktuell rund 600 Sterne, ist nicht archiviert und wurde zuletzt am 23. Oktober 2026 aktualisiert. Laut README funktioniert der Server mit dbt Core, dbt Fusion und der dbt Platform.

Was kann der dbt MCP Server?

Laut Dokumentation und README gliedert sich der Funktionsumfang in mehrere Werkzeugkategorien. Der Semantic Layer liefert Metriken, Dimensionen, Entitäten und gespeicherte Abfragen, sodass ein Assistent Kennzahlen konsistent abfragen kann, statt eigenes SQL zu erfinden. Die Metadaten-Erkundung (Discovery) beschreibt Modelle, Quellen, Lineage und den Gesundheitszustand von Daten. Über die Administrations-API lassen sich Jobs, Läufe, Artefakte und Fehler einsehen sowie Läufe auslösen und wiederholen. Für SQL gibt es Werkzeuge zum Ausführen von Abfragen und zum Erzeugen von SQL aus natürlicher Sprache. Lokal kommen die dbt-CLI-Befehle wie build, run und test hinzu, dazu Codegenerierung für YAML und Staging-Modelle sowie Werkzeuge der neueren dbt-Engine, etwa Spalten-Lineage. Außerdem gibt es Werkzeuge für die Produktdokumentation und Metadaten des Servers selbst.

Lokal oder remote?

Es gibt zwei Betriebsarten. Der lokale Server läuft auf Ihrem Rechner und wird laut Dokumentation mit uvx dbt-mcp gestartet; er eignet sich für die Entwicklung, weil er auch die CLI-Befehle und die Codegenerierung anbietet. Ein dbt-Platform-Konto ist dafür optional. Der Remote-Server wird von dbt gehostet, verlangt keine Installation und setzt ein dbt-Platform-Konto voraus; er ist auf den Datenkonsum ausgelegt, also Metriken, Metadaten und Lineage, und bietet die CLI- und Codegenerierungswerkzeuge nicht an. Für den Remote-Server nennt die Dokumentation ein Limit von 5.000 Anfragen pro Minute und IP-Adresse. Welche Werkzeuge nutzbar sind, hängt auch vom Plan ab, weil die zugrunde liegenden APIs je nach Tarif unterschiedlich verfügbar sind. Für die Anmeldung unterstützt die Dokumentation je nach Aufbau und Client OAuth oder Token.

Wofür ist er besonders nützlich?

Der größte Nutzen liegt dort, wo Datenteams ständig Kontext nachschlagen. Ein Analyst fragt, welche Modelle von einer Quelle abhängen, bevor sie geändert wird; ein Analytics Engineer lässt sich Staging-Modelle und YAML-Gerüste erzeugen und anschließend per CLI testen; ein Fachbereich fragt über den Semantic Layer nach einer Kennzahl und bekommt eine Antwort auf Basis der gepflegten Metrikdefinition. Auch die Fehlersuche profitiert: Der Assistent liest fehlgeschlagene Läufe samt Fehlermeldungen und schlägt eine Korrektur vor. Gegenüber einem allgemeinen Datenbank-Server unterscheidet sich der dbt MCP Server dadurch, dass er die fachliche Schicht kennt, also Modelle, Metriken und Abhängigkeiten, und nicht nur Tabellen.

Sicherheit: was Sie beachten sollten

Die dbt-CLI-Werkzeuge können laut README Daten und Objekte im Warehouse verändern. Lassen Sie build und run deshalb zunächst in einer Entwicklungsumgebung laufen und prüfen Sie die Rechte der verwendeten Zugangsdaten. Das Auslösen und Wiederholen von Jobs über die Administrations-API hat Folgen für Produktionsläufe und Kosten im Warehouse. Laut Dokumentation speichert der Server keine Produktionsdaten oder Job-Ergebnisse, sondern liest sie bei jedem Aufruf aus; abgerufene Inhalte gelangen dennoch in den Kontext des KI-Clients. Hinweis zum Reifegrad: Das MCP-Bundle der README wird als experimentell bezeichnet, einzelne Werkzeuge sind als Alpha oder veraltet markiert. Die genaue Werkzeug- und Variablenliste entnehmen Sie der offiziellen Dokumentation.

Kosten

Der MCP-Server selbst ist unter Apache-2.0 kostenlos. Für den Remote-Betrieb und die Platform-Werkzeuge ist ein dbt-Platform-Konto nötig. Laut Preisseite gibt es einen kostenlosen Entwicklerplan mit begrenztem Umfang, der allerdings keinen API-Zugang enthält, dazu einen kostenpflichtigen Starter-Plan mit Testphase sowie Enterprise-Tarife auf Anfrage. Aktuelle Konditionen finden Sie auf der offiziellen Preisseite von dbt.

Für wen lohnt sich der dbt MCP Server?

Er lohnt sich für Data Engineers, Analytics Engineers und Analysten, die bereits mit dbt arbeiten und ihren Assistenten mit echtem Projektkontext ausstatten wollen. Ohne dbt-Projekt bringt er wenig. Beginnen Sie lokal mit uvx dbt-mcp in einer Entwicklungsumgebung, nutzen Sie zunächst lesende Werkzeuge wie Discovery und Semantic Layer und schalten Sie schreibende CLI-Befehle erst frei, wenn Sie den Ablauf kennen.

Lokal: uv (für uvx) und ein MCP-Client wie Claude Code oder Cursor; ein dbt-Platform-Konto ist optional. Remote: dbt-Platform-Konto und ein MCP-Client mit Unterstützung für HTTP-Server.

Mit dem dbt MCP Server gibt ein KI-Assistent Auskunft über Modelle, Lineage und Metriken Ihres dbt-Projekts. Dieser Ratgeber führt von der Wahl der Betriebsart bis zur ersten Abfrage.

Betriebsart wählen

Der lokale Server eignet sich für die Entwicklung, weil er auch dbt-CLI-Befehle und Codegenerierung anbietet. Der Remote-Server der dbt Platform braucht keine Installation und ein Konto bei der dbt Platform; er ist für den Datenkonsum gedacht, also Metriken, Metadaten und Lineage.

Schritt 1: Lokal einrichten

Installieren Sie uv und tragen Sie den Server im MCP-Client ein. In Claude Code lautet der Grundbefehl claude mcp add dbt -- uvx dbt-mcp. Welche Umgebungsvariablen Sie für Projektpfad oder Platform-Anbindung setzen, steht in der Umgebungsvariablen-Referenz der dbt-Dokumentation; einzelne Werkzeuge lassen sich dort auch abschalten.

claude mcp add dbt -- uvx dbt-mcp

Schritt 2: Remote einrichten

Binden Sie den gehosteten Server per HTTP in Ihren Client ein und melden Sie sich per OAuth oder Token an. Die Dokumentation enthält Leitfäden für Claude, Cursor und VS Code. Beachten Sie das Limit von 5.000 Anfragen pro Minute und IP-Adresse.

Risiken begrenzen

Die CLI-Werkzeuge können Daten im Warehouse verändern. Arbeiten Sie zunächst in einer Entwicklungsumgebung mit eng gefassten Rechten, und prüfen Sie, bevor der Assistent Jobs auslöst oder wiederholt, was ein Lauf in Produktion bewirkt.

Schritt 3: Erste Abfragen

Beginnen Sie lesend, etwa „Welche Modelle hängen von der Quelle orders ab?“ oder „Welche Metriken gibt es im Semantic Layer?“. Erst danach lassen Sie Staging-Modelle erzeugen oder Tests ausführen.

Je nach Aufbau und Client OAuth oder Token für die dbt Platform; rein lokale CLI-Nutzung arbeitet mit Ihrem lokalen dbt-Projekt.

Lesender Zugriff auf Metadaten, Lineage, Metriken und Jobs sowie SQL-Abfragen; lokal zusätzlich dbt-CLI-Befehle, die Daten und Objekte im Warehouse verändern können, und über die Administrations-API das Auslösen und Wiederholen von Läufen.

Laut Dokumentation speichert der Server keine Produktionsdaten oder Job-Ergebnisse, sondern liest sie bei jedem Aufruf aus. Abgerufene Modelle, Metadaten und Abfrageergebnisse gelangen in den Kontext des KI-Clients und damit zum Modellanbieter.

Unbeabsichtigte Änderungen am Warehouse durch dbt build oder run, ungeplantes Auslösen von Produktionsjobs, zu weit gefasste Zugangsdaten, Kosten durch große Abfragen sowie Prompt Injection über Beschreibungen oder Abfrageinhalte.