dbt MCP Server

The dbt MCP Server connects AI assistants such as Claude Code or Cursor to your dbt projects and the data dbt manages. dbt is the common tool for maintaining warehouse transformations as code; the MCP server gives an assistant context about which models exist, how they relate, which metrics are defined, and whether data is fresh. Instead of looking up model names and dependencies yourself, you ask in natural language and the assistant calls the matching tools. The project lives in the GitHub organization dbt-labs, is released under the Apache 2.0 license, currently has around 600 stars, is not archived, and was last updated on October 23, 2026. According to the README the server works with dbt Core, dbt Fusion, and the dbt Platform.

What can the dbt MCP Server do?

According to the documentation and README the feature set is split into several tool categories. The semantic layer provides metrics, dimensions, entities, and saved queries, so an assistant can query figures consistently instead of inventing its own SQL. Metadata discovery describes models, sources, lineage, and the health of data. Through the administrative API you can inspect jobs, runs, artifacts, and errors, and trigger and retry runs. For SQL there are tools to execute queries and to generate SQL from natural language. Locally, the dbt CLI commands such as build, run, and test are added, along with code generation for YAML and staging models and tools from the newer dbt engine, such as column-level lineage. There are also tools for the product documentation and metadata about the server itself.

Local or remote?

There are two modes of operation. The local server runs on your machine and, according to the documentation, is started with uvx dbt-mcp; it suits development because it also offers the CLI commands and code generation. A dbt Platform account is optional for it. The remote server is hosted by dbt, needs no installation, and requires a dbt Platform account; it is aimed at data consumption, meaning metrics, metadata, and lineage, and does not offer the CLI and code generation tools. For the remote server the documentation names a limit of 5,000 requests per minute per IP address. Which tools you can use also depends on the plan, because the underlying APIs are available differently across tiers. For sign-in the documentation supports OAuth or token, depending on the setup and client.

What is it particularly useful for?

The greatest value lies where data teams constantly look up context. An analyst asks which models depend on a source before changing it; an analytics engineer has staging models and YAML scaffolding generated and then tests them via the CLI; a business team asks about a figure through the semantic layer and gets an answer based on the maintained metric definition. Troubleshooting benefits too: the assistant reads failed runs together with their error messages and suggests a fix. Compared with a general database server, the dbt MCP Server differs in that it knows the business layer, meaning models, metrics, and dependencies, and not just tables.

Security: what to keep in mind

According to the README, the dbt CLI tools can change data and objects in the warehouse. Therefore run build and run in a development environment first and check the permissions of the credentials you use. Triggering and retrying jobs through the administrative API affects production runs and warehouse costs. According to the documentation the server does not store production data or job results but reads them on every call; retrieved content still enters the AI client's context. A note on maturity: the MCP bundle in the README is described as experimental, and individual tools are marked alpha or deprecated. For the exact list of tools and variables, consult the official documentation.

Costs

The MCP server itself is free under Apache 2.0. Remote operation and the platform tools require a dbt Platform account. According to the pricing page there is a free developer plan with limited scope that does not include API access, a paid starter plan with a trial period, and enterprise tiers on request. Current terms are on dbt's official pricing page.

Who is the dbt MCP Server for?

It is worthwhile for data engineers, analytics engineers, and analysts who already work with dbt and want to equip their assistant with real project context. Without a dbt project it adds little. Start locally with uvx dbt-mcp in a development environment, use read-oriented tools such as discovery and the semantic layer first, and enable write-capable CLI commands only once you know the flow.

Local: uv (for uvx) and an MCP client such as Claude Code or Cursor; a dbt Platform account is optional. Remote: dbt Platform account and an MCP client that supports HTTP servers.

With the dbt MCP Server an AI assistant gives information about models, lineage, and metrics of your dbt project. This guide leads from choosing the mode of operation to the first query.

Choose the mode

The local server suits development because it also offers dbt CLI commands and code generation. The remote server of the dbt Platform needs no installation and an account with the dbt Platform; it is meant for data consumption, meaning metrics, metadata, and lineage.

Step 1: Set up locally

Install uv and register the server in the MCP client. In Claude Code the basic command is claude mcp add dbt -- uvx dbt-mcp. Which environment variables you set for the project path or platform connection is listed in the environment variable reference of the dbt documentation; individual tools can be switched off there too.

claude mcp add dbt -- uvx dbt-mcp

Step 2: Set up remotely

Connect the hosted server to your client via HTTP and sign in with OAuth or a token. The documentation has guides for Claude, Cursor, and VS Code. Note the limit of 5,000 requests per minute per IP address.

Limit the risks

The CLI tools can change data in the warehouse. Work in a development environment with narrow permissions first, and before the assistant triggers or retries jobs, check what a run does in production.

Step 3: First queries

Start with reads, such as "Which models depend on the source orders?" or "Which metrics exist in the semantic layer?". Only then have staging models generated or tests run.

OAuth or token for the dbt Platform, depending on the setup and client; purely local CLI use works with your local dbt project.

Read access to metadata, lineage, metrics, and jobs as well as SQL queries; locally additionally dbt CLI commands that can change data and objects in the warehouse, and through the administrative API triggering and retrying runs.

According to the documentation the server does not store production data or job results but reads them on every call. Retrieved models, metadata, and query results enter the AI client context and therefore reach the model provider.

Unintended warehouse changes through dbt build or run, unplanned triggering of production jobs, overly broad credentials, costs from large queries, and prompt injection via descriptions or query content.