Category · Data stack MCP servers
dbt MCP Server: Bringing AI Agents Into the Transformation Layer
A dbt MCP server matters for one reason: an assistant writing or reviewing dbt models needs to see the warehouse those models run against. Without that, it is guessing at column names, types, and row counts. dbt Labs has been building official MCP support, and alongside it the warehouse and database servers in our directory are what make model work actually grounded. This page covers how the pieces fit together in 2026.
What this category covers
Data-stack MCP servers connect an assistant to the systems where analytics work happens: warehouses, databases, and the transformation layer on top of them. dbt sits in that transformation layer, and dbt Labs maintains official MCP support for it — check the dbt documentation for current capabilities, since this is an actively developing integration. Our directory currently lists the surrounding pieces: ClickHouse, PostgreSQL, Supabase, and MongoDB servers that give an assistant access to the underlying data. For a broader view of query-layer options, see our SQL MCP server page.
How it works
The useful pattern is layered. A warehouse or database MCP server lets the assistant inspect real schemas, column types, and sample rows — the Postgres MCP server is the most common starting point. A filesystem or Git server gives it access to your dbt project — models, tests, and YAML config under version control. Together these let it write a model against columns that exist, or review a pull request knowing what the upstream table actually contains, rather than inferring structure from naming conventions.
Buying guide
Connect the warehouse with read-only credentials — this is the single most important setup decision here. An assistant with write access to an analytics warehouse can drop or overwrite tables, and the value it provides in this workflow comes entirely from reading schemas and sampling data, not from mutating it. Second, be deliberate about what sampling means: if your tables contain customer PII, every sampled row enters the conversation and is sent to your AI provider, so query against anonymised views or restrict the credential to non-sensitive schemas. Third, pair the warehouse server with repository access, because a dbt model reviewed without its git history and its tests is being reviewed with half the context. Teams on a cloud warehouse should also read our Snowflake MCP server guide. For the dbt-specific integration itself, check dbt Labs' current documentation — capabilities in this area have been moving quickly.
The Tools, Ranked
Query and explore ClickHouse databases with AI. Free and open source, and one of the more common warehouses behind a dbt project.
Direct Postgres access — schema inspection, sample queries, and row counts that ground model logic in reality.
Query and manage a Supabase project, covering Postgres plus auth and storage for teams whose source data lives there.
Full MongoDB access for pipelines that ingest from document stores rather than relational sources.
Reads commits and diffs on your dbt project, so an assistant can explain why a model was changed as well as what it does.
dbt changes ship through pull requests. Repository access gives the assistant the diff and the surrounding discussion.
Scoped to the dbt project directory, this covers models, macros, tests, and YAML configuration on disk.