The dbt MCP Server is dbt Labs’ own first-party server, and it is unusually large: 61 tools across nine toolsets, covering dbt Core, dbt Fusion and the dbt platform from one process. Built by dbt Labs, it is officially maintained and best for Database.
by dbt Labs
About
The dbt MCP Server is dbt Labs’ own first-party server, and it is unusually large: 61 tools across nine toolsets, covering dbt Core, dbt Fusion and the dbt platform from one process. The Discovery toolset reads your project’s metadata graph — get_all_models, get_lineage, get_node_details, get_model_health and get_model_performance answer “what does this model depend on and did it pass last night” without opening the warehouse. The Semantic Layer toolset (list_metrics, query_metrics, get_dimensions, get_metrics_compiled_sql) is the one that makes governed numbers possible: the agent queries your defined metrics rather than inventing SQL against raw tables. The dbt CLI toolset runs build, run, test, compile, parse, show and list against a local project, and the Admin API toolset triggers, retries, cancels and inspects platform job runs. Codegen (generate_source, generate_staging_model, generate_model_yaml), Fusion column-level lineage, and product-docs search round it out. It ships in two flavours. Self-hosted runs beside your client via `uvx dbt-mcp` and is the only flavour that can execute dbt CLI commands or Codegen; the remote server at /api/ai/v1/mcp/ on your dbt platform host needs no install but is consumption-only. Auth is either DBT_TOKEN or an interactive OAuth login that caches its context in ~/.dbt/mcp.yml — and the fallback between them is silent, which is the single most common way a first run appears to hang. Python 3.12 or 3.13 only; 3.14 is blocked on pyarrow wheels.
Trust verdict
How grades are computed →Grade A (98/100, reliable) from 1 measured signal, based on repository evidence. Only one signal stands behind it, so treat the grade as provisional.
What was measured
- Repository maintenance100/100 · weight 20
The repository has been pushed to or released within the last six months. — last push 2026-07-24, last release 2026-07-20 (v1.22.1).
- Source verification100/100 · weight 25
The repository URL was confirmed to resolve against the live GitHub API and is not archived.
- Provenance90/100 · weight 10
Published and maintained by the vendor of the service it connects to, rather than by a third party.
- Listing ↔ repository match100/100 · weight 5
The listing name lines up with the linked repository dbt-labs/dbt-mcp.
What could not be measured
These contributed nothing to the score — not a penalty, not a zero. They are why the confidence reads the way it does.
- Live MCP handshakeunknown
No remote endpoint to handshake — this server installs and runs locally over stdio, so there is nothing to probe from the outside.
- Measured uptimeunknown
No probe history recorded for this server yet.
- Tool-schema stabilityunknown
Drift is a difference between two successive checks, and this server has none recorded.
Installation
uvx dbt-mcpdbt-mcp confirmed live on PyPI — checked August 17, 2026.
dbt Labs publishes this one themselves, so — as with Tableau — the question is not which project to trust but which flavour to run. The remote server, reached over HTTP at /api/ai/v1/mcp/ on your dbt platform host, needs nothing installed and is the right default if the agent is going to read metadata and query metrics. It cannot run dbt CLI commands or Codegen, and it never will: those tools need a checkout on disk. The self-hosted server, started with uvx dbt-mcp beside your client, is the one for development workflows — it is the only flavour that can run dbt build, dbt test or generate a staging model, and it can still reach the platform APIs on top. The surface is large either way: 61 tools across nine toolsets, more than most clients will happily show at once, which is why the enable/disable configuration below matters more here than on a five-tool server. Read the gotchas before your first run; two of the three most common failures are silent by design.
Connecting the dbt MCP server
1.Check your Python version before anything else
pyproject.toml pins requires-python to >=3.12,<3.14. The upper bound is deliberate and is commented in the file: pyarrow has not released 3.14 wheels. On a 3.14 interpreter uv will fail to resolve rather than fail to run, which reads like a network problem and is not one.
shellpython3 --version # must be 3.12.x or 3.13.x2.Decide remote or self-hosted
If the agent only needs to explore metadata, read lineage and query Semantic Layer metrics, point your client at the remote server on your own dbt platform host and skip the rest of the install. The remote flavour supports the Semantic Layer, SQL, Discovery, Admin API, Fusion, product-docs and metadata toolsets — but not the dbt CLI toolset and not Codegen. Continue below only if you want those, or you want the server running on your own machine against a local project.
remote endpointhttps://<your-account-prefix>.<your-host>/api/ai/v1/mcp/3.Install uv, not pip
The published console script is dbt-mcp and the documented way to start it is uvx dbt-mcp, which resolves the package into an isolated environment on each run. A bare pip install dbt-mcp puts the package somewhere, but it does not give your MCP client a command it can find, and a dbt-mcp installed into the same environment as your dbt adapters is exactly the dependency conflict uv exists to avoid. Latest release is 2.1.2 (2026-08-20).
shellcurl -LsSf https://astral.sh/uv/install.sh | sh uvx dbt-mcp --help4.Add the server to your MCP client
DBT_PROJECT_DIR must point at a directory that contains dbt_project.yml, and DBT_PATH must be a dbt executable that actually exists — settings.py validates both, and dbt and dbtf are the two names it will accept from $PATH without a full path. If you are only using platform tools and have no local checkout, leave both out and set DISABLE_DBT_CLI=true so the CLI toolset does not try to load.
claude_desktop_config.json{ "mcpServers": { "dbt": { "command": "uvx", "args": ["dbt-mcp"], "env": { "DBT_PROJECT_DIR": "/absolute/path/to/your/dbt/project", "DBT_PATH": "dbt", "DBT_HOST": "your-host.dbt.com", "DBT_TOKEN": "your_service_token", "DBT_PROD_ENV_ID": "12345", "DBT_DEV_ENV_ID": "67890", "DBT_USER_ID": "1122" } } } }5.Set every platform variable the toolsets you want actually require
This is where most configurations fall over, because the requirements are per-toolset and the error only appears once. Semantic Layer, Discovery, SQL and the Admin API all need DBT_HOST, DBT_TOKEN and either DBT_PROD_ENV_ID or DBT_PROJECT_IDS — setting both of the last two is an error, not a merge. execute_sql additionally needs DBT_DEV_ENV_ID and DBT_USER_ID, and text_to_sql needs DBT_PROD_ENV_ID specifically. DBT_HOST is the bare hostname: strip the scheme, and note that a value beginning with metadata or semantic-layer is rejected outright, because those are the API subdomains people reach for and neither is the right one.
6.Trim the tool list before you hand it to an agent
Sixty-one tools is more than most clients present well and more than most models choose well between. Two toolsets already ship off — Codegen (DISABLE_DBT_CODEGEN defaults true) and server metadata — and SQL is off unless you explicitly set DISABLE_SQL=false. Prefer the allowlist: set DBT_MCP_ENABLE_TOOLS to just the tools you want, or the DBT_MCP_ENABLE_* flags for whole toolsets. Individual tool settings beat toolset settings, and enables beat disables at the same level.
envDBT_MCP_ENABLE_TOOLS="list_metrics,query_metrics,get_all_models,get_lineage"7.Smoke test with a metadata call, not a query
Ask for the model list first. get_all_models exercises the host, the token and the environment id together without depending on the Semantic Layer being configured or the warehouse being reachable, so a failure points at one layer. Only then try a metric query.
promptList every model in my dbt project and tell me which marts have failing tests.
The nine toolsets
61 tools in total. Everything except the dbt CLI and Codegen toolsets is available on the remote server as well as self-hosted.
DiscoveryThe metadata graph: get_all_models, get_all_sources, get_mart_models, get_node_details, get_lineage, get_model_health, get_model_performance, get_related_models. Several older per-type tools (get_model_details, get_source_details, get_model_parents/children) are deprecated in favour of get_node_details and get_lineage.
Semantic Layerlist_metrics, list_saved_queries, query_metrics, get_dimensions, get_dimension_values, get_entities, get_metrics_compiled_sql. The governed path — the agent asks for your defined metrics instead of writing SQL against raw tables.
dbt CLIbuild, run, test, compile, parse, show, list, clone, docs, plus get_lineage_dev and get_node_details_dev which read the local manifest.json. Self-hosted only, and the toolset that can modify your warehouse.
Admin APIlist_projects, list_jobs, get_job_details, trigger_job_run, retry_job_run, cancel_job_run, list_jobs_runs, get_job_run_details, get_job_run_error, list_job_run_artifacts.
SQLexecute_sql (runs against dbt platform infrastructure, with Semantic Layer support) and text_to_sql. Off by default — see the gotcha on DISABLE_SQL.
Codegengenerate_source, generate_staging_model, generate_model_yaml. Boilerplate for new models. Self-hosted only and disabled by default.
dbt LSP / Fusionget_column_lineage (local, needs dbt-lsp from the dbt Labs VS Code extension), fusion.get_column_lineage and fusion.compile_sql (via dbt platform). Column-level lineage, which the Discovery tools do not give you.
Product docssearch_product_docs and get_product_doc_pages, which search and fetch docs.getdbt.com. Useful for stopping an agent inventing dbt syntax.
Server metadataget_mcp_server_version and get_mcp_server_branch. Disabled by default; worth enabling only while debugging a version mismatch.
What people use it for
Answer a metric question without letting the agent write SQL
“What was weekly revenue by product line for the last 8 weeks? Use the defined metrics, not raw tables.”
query_metrics goes through the Semantic Layer, so the numbers match the ones in your BI tool by construction. This is the whole argument for putting dbt in front of an agent rather than a warehouse connector: the join logic and the filters are already governed.
Triage a failed nightly run
“The last run of our nightly job failed. Find the run, get the error, and tell me which models downstream of the failure did not build.”
get_job_run_error and get_lineage together do the thing a person does by hand across two browser tabs — read the error out of the Admin API, then walk the DAG to find the blast radius.
Assess a change before making it
“I want to change the grain of fct_orders. Show me everything downstream, including exposures, and which of those have tests.”
get_lineage returns descendants with type and depth filtering, and get_exposures surfaces the dashboards nobody remembers are wired to the model. This is the question the catalog UI answers slowly and the agent answers in one turn.
Draft the boilerplate for a new source
“Generate the source YAML for the raw.stripe schema with columns, then a staging model for raw.stripe.charges.”
generate_source and generate_staging_model introspect the warehouse rather than guessing column names. Requires the self-hosted server and DBT_MCP_ENABLE_DBT_CODEGEN=true, since Codegen ships off.
Which one should you use?
dbt is the semantic/transformation layer, so the real comparison is not against other dbt servers — there is only one — but against connecting the agent somewhere else in the stack.
A direct warehouse MCP server (Snowflake, BigQuery, Postgres)
The warehouse server if you want raw table access and are willing to let the model write its own joins. dbt if you want the numbers to match your BI tool — the Semantic Layer tools query metrics you have already defined and tested.
Tableau
Tableau if the metrics live in published datasources and the audience is analysts. dbt if the metrics live in your dbt project and the audience is the people who build the models.
Databricks
Databricks for Unity Catalog governance and notebook/job control. dbt if the transformation logic — not the compute — is what the agent needs to understand.
Power BI
Power BI when the semantic model is a Power BI dataset. These are not really alternatives; run both if your metrics are defined in both places, which is more common than anyone likes.
Every command, environment variable, and endpoint above was read from the project’s own documentation on 2026-08-24: dbt-labs/dbt-mcp README (tool list by toolset), Official dbt MCP documentation, src/dbt_mcp/config/settings.py (every env var, the validators, the auto-disable), src/dbt_mcp/config/credentials.py (the OAuth fallback and ~/.dbt/mcp.yml), src/dbt_mcp/tools/register.py (enable/disable precedence rules), pyproject.toml (Python floor, entry point) and CHANGELOG.md (v2.1.2, 2026-08-20), PyPI dbt-mcp 2.1.2.
Categories
Works With
Frequently Asked Questions
Why does the dbt MCP server hang on first run instead of returning an error?
Why are the dbt CLI tools missing from my tool list?
Why did setting DBT_MCP_ENABLE_TOOLS remove every tool?
Why are execute_sql and text_to_sql not available?
Can the dbt MCP server modify my warehouse?
Does the remote dbt MCP server consume dbt Copilot actions?
Which dbt platform plan do I need?
Does the dbt MCP server send telemetry?
What is dbt MCP Server?
Who built dbt MCP Server?
Is dbt MCP Server free?
How do I install dbt MCP Server?
What does dbt MCP Server integrate with?
Related Guides
Best MCP Servers for Data Science & Analytics in 2026
8 min read • Guides
Best MCP Servers for Analytics and Data Teams in 2026
8 min read • Guides
Best MCP Servers for Python Developers in 2026
9 min read • Guides
Best MCP Servers for Jupyter Notebook Users in 2026
7 min read • Guides
Best MCP Servers for Snowflake Developers in 2026
7 min read • Guides
Repo Health
Local/stdio install — runs on your machine, so there is no remote endpoint to verify live. Trust signal below is from the source repo.
- Last commit
- 1mo ago
- Last release
- v1.22.1 · 1mo ago
- Install
- pip
- Package
- dbt-mcp
Quick Info
- Install Type
- pip
- Author
- dbt Labs
- Categories
- 3
- Integrations
- 4
Related Servers
Git
Tools to read, search, and manipulate Git repositories. Full Git operations support.
GitHub MCP Server
authenticated access to the whole GitHub platform — repositories, files, branches, issues, pull requests, Actions runs, security alerts, discussions and notifications — from Claude, Cursor, VS Code, Copilot CLI and any other MCP host. There is no npm package for this server, and that trips up most people who try to install it: `@github/mcp-server` is not published to the npm registry, so any `npx` line you find for it will fail. GitHub ships it three other ways. The easiest is the hosted remote server at https://api.githubcopilot.com/mcp/, which needs no install at all — point an HTTP-transport MCP client at that URL and log in with OAuth (VS Code 1.101+, Claude Desktop, Claude Code, Cursor and Windsurf all support this). The second is the official Docker image ghcr.io/github/github-mcp-server, which is what the copy-paste command on this page runs; on github.com it now performs a browser-based OAuth login on first use and keeps the token in memory only, which is why the published Docker configs map a fixed loopback callback port (-p 127.0.0.1:8085:8085 with GITHUB_OAUTH_CALLBACK_PORT=8085) so the container can receive the callback. Prefer a token? Set GITHUB_PERSONAL_ACCESS_TOKEN instead — it takes precedence over OAuth, and the minimum useful scopes are repo, read:org and read:packages. The third is the native Go binary from the repository's releases, which needs no fixed port for the OAuth flow. GitHub Enterprise Server has no hosted option: use the local server with --gh-host or GITHUB_HOST set to your instance (include the https:// scheme — it defaults to http://, which GHES rejects). Toolsets can be narrowed with GITHUB_TOOLSETS, and an insiders channel is available at /mcp/insiders or via the X-MCP-Insiders header.
GitLab MCP Server
a first-party MCP endpoint built into the GitLab instance itself — there is no package to install, because the server ships inside GitLab and answers at https://<your-gitlab>/api/v4/mcp (gitlab.com exposes the same path, so https://gitlab.com/api/v4/mcp works for SaaS projects). It landed as an experiment in GitLab 18.3 and moved to beta in 18.6. Authentication is the part that makes it different from every community GitLab server: it uses OAuth 2.0 Dynamic Client Registration, so the first time a client connects it registers itself as an OAuth application on your instance and is issued an access token — no personal access token pasted into a config file. Administrators who do not want one OAuth application per tool can pre-create a shared application instead. Three prerequisites are what actually block most first connections: GitLab Duo must be set to Always on or On by default, beta and experimental features must be enabled, and MCP access must be switched on at the group or instance level. The tool surface covers issues and merge requests (create_issue, get_issue, create_merge_request, get_merge_request, list_merge_requests, get_merge_request_commits, get_merge_request_diffs, get_merge_request_pipelines, create_merge_request_note, get_merge_request_notes), CI/CD (manage_pipeline for list/create/delete/retry/cancel, get_pipeline_jobs, get_job_log), work items (create_workitem_note, get_workitem_notes, link_work_items, get_saved_view_work_items), search (search across the instance, search_labels, semantic_code_search), list_wiki_pages, and attach_scan_profile. HTTP is the recommended transport — claude mcp add --transport http GitLab https://gitlab.com/api/v4/mcp — and clients that only speak stdio can wrap it with npx mcp-remote <url> on Node 20+. Send the X-Gitlab-Mcp-Server-Tool-Name-Prefix header if generic names like search collide with another connected server. If your instance predates 18.3 or Duo is not available to you, the community alternative most teams land on is zereight/gitlab-mcp (1,889 stars as of 2026-08-16, npm @zereight/mcp-gitlab), which authenticates with a plain personal access token and ships 217 tools — including merge_merge_request, approve_merge_request, execute_graphql and full CI/CD variable management, none of which the built-in server exposes — behind GITLAB_PERMISSION_MODE=readonly/modify and GITLAB_TOOLSETS/GITLAB_TOOLS filtering. One further change worth noting: MCP server access moved from GitLab Premium to GitLab Free in 19.2 and became a setting of its own.
AWS MCP Servers
AWS Labs maintains a monorepo of specialized, open-source MCP servers that bring AWS best practices directly into AI-assisted development workflows, spanning infrastructure, data, AI/ML, cost management, and healthcare/life-sciences domains. Rather than one monolithic server, the project ships dozens of focused servers you install individually depending on the task: the AWS Documentation MCP Server for real-time official docs and API references, dedicated servers for Terraform/CDK/CloudFormation infrastructure-as-code, container and serverless platforms (ECS, EKS, Lambda), SQL/NoSQL databases (DynamoDB, RDS, Aurora), search and analytics (OpenSearch), messaging (SQS/SNS), and cost/billing analysis. Most servers install via uvx with a package name like awslabs.aws-documentation-mcp-server, run locally over stdio, and use standard AWS credential chains (IAM roles, profiles, or access keys) rather than exposing raw account credentials to the model. AWS also now offers a managed, remote "AWS MCP Server" (in preview) that combines full API coverage with pre-built agent SOPs, syntactically validated API calls, and complete CloudTrail audit logging for teams that want centralized governance instead of running servers locally. The Getting Started with Kiro/Cursor/VS Code/Claude Code sections in the repo provide one-click install configs for each server, making it straightforward to wire up only the AWS services a given project actually touches.
Cloudflare MCP Server
Cloudflare ships two different things under this name. The mcp-server-cloudflare repo provides 16 remote, domain-specific MCP servers rather than one monolith — Documentation, Workers Bindings (storage/AI/compute primitives), Workers Builds, Observability (logs/analytics), Container sandboxes, Browser Rendering (fetch pages, convert to markdown, screenshots), Logpush health, AI Gateway (prompt/response search), AI Search, Audit Logs, DNS Analytics, Digital Experience Monitoring, Cloudflare One CASB, Radar, GraphQL analytics and the Agents SDK docs server, each on its own `*.mcp.cloudflare.com/mcp` hostname. Separately, the Cloudflare API MCP server at mcp.cloudflare.com/mcp (repo: cloudflare/mcp) exposes the whole 2,500+ endpoint Cloudflare API through just two tools, `search` and `execute`, using the Code Mode pattern — model-written JavaScript runs in an isolated Dynamic Worker, costing ~1,000 tokens of context against the ~1.17M an equivalent native-tool server would need. Pick a domain server when you want a readable, curated tool list for one product area; pick the API server for breadth or for endpoints nobody wrote a tool for. All endpoints are Streamable HTTP on `/mcp` and support the MCP 2026-07-28 spec; the historical `/sse` URLs remain as aliases for the same Streamable HTTP handler but no longer serve the deprecated HTTP+SSE transport, so clients pinned to SSE must switch. Auth is OAuth on connect, or a scoped Cloudflare API token as a bearer header for CI. Clients without native remote-MCP support bridge via `npx mcp-remote https://<subdomain>.mcp.cloudflare.com/mcp`.
Sponsored
Better Stack
Free PlanGet alerted when your APIs, browser tests, payment pipelines, or MCP server dependencies go down. Used by 100K+ developers.
Start monitoring free →