MCP Server for dbt: How It Works & What's Missing

Why does the dbt MCP server matter?

Business semantics are captured and refined throughout the ETL or ELT process, with data transformation as a key stage. As the dbt Semantic Layer documentation makes clear, most of the business logic that drives reporting, analysis, and AI-readable metrics resides in the transformation layer.

This is the core problem the dbt MCP server solves: without it, AI agents have no reliable way to read that logic. Three things make the dbt MCP server meaningful for AI teams:

• Business logic centralization: MCP server makes business definitions agent-readable without extra documentation.

• Metric governance at query time: MetricFlow enforces consistent metric definitions at the point of query, and so, agents get the same metric every time.

• Lineage as context: Data lineage captured through dbt runs tells agents about the origins and dependencies of each metric.

What does the dbt MCP server involve?

The dbt MCP server sits between the dbt Semantic Layer and any MCP-compatible agent or tool. Three components work together to make this possible.

The Model Context Protocol (MCP)

MCP is an open standard, originally introduced by Anthropic, that defines how AI agents discover and consume context from external systems at inference time. It standardizes the interface between agent reasoning layers and external knowledge sources, so any MCP-compatible agent can query any MCP-compatible server using the same protocol.

The dbt Semantic Layer

The dbt Semantic Layer is dbt’s framework for defining metrics, dimensions, and entities separately from the underlying data models. It centralizes business definitions so they can be consumed consistently across BI tools, AI agents, and other downstream systems.

MetricFlow

MetricFlow is the metric definition layer within dbt. Data teams use it to specify how metrics are calculated, which dimensions they can be sliced by, which entities they belong to, and which aggregations are valid.

What can you do with the MCP server for dbt?

The dbt MCP server allows agents and users to access various tools that dbt exposes. As of April 2026, there are eight toolsets available for accessing various dbt features. One of these toolsets gives external agents access to the dbt Semantic Layer using the following six tools:

1. list_metrics: Allows agents to retrieve all the metrics defined in your dbt project.
2. get_dimensions: Lets agents fetch the dimensions for you to slice a particular metric.
3. get_entities: Lets agents get the entities (join keys) available for a particular metric.
4. query_metrics: Allows agents to execute queries based on metric definitions.
5. list_saved_queries: Lets agents fetch all the saved queries.
6. get_metrics_compiled_sql: Allows agents to get a compiled SQL query for a metric using MetricFlow.

The other two toolsets that work closely with the Semantic Layer toolset are:

• SQL tools: Helpful in natural language to SQL query translation.

• Metadata Discovery tools: Provide context to the Semantic Layer tools.

How can you set up the dbt MCP server for agents?

Before setting up the dbt MCP server, ensure you have a dbt platform account and a dbt project deployed in a production environment.

The dbt platform Account Admin will need to create credentials in the form of a Personal Access Token (PAT), or more likely, a Service Token with the right permission to call Semantic Layer tools, Metadata Discovery tools, and the Developer APIs.

To interact with the MCP server, the agent will need to route through an MCP client. Here are the steps to create this MCP server:

1. Define metrics on top of your semantic models.
2. Enable the Semantic Layer and connect it to the data warehouse.
3. Figure out authentication and authorization (PAT/Service Token).
4. Get the connection details with the DBT_HOST value.
5. Get the production environment ID from the dbt platform.
6. Use a remote MCP endpoint (local is also possible for some use cases).
7. Integrate the dbt MCP server with your MCP client.

Once you connect to the dbt MCP server, any AI agents you have will be able to reap the benefits of the toolsets that the server exposes. That said, the dbt MCP server, while it provides access to the dbt Semantic Layer, cannot address organizational semantics and context.

Why is the dbt MCP server alone not enough?

Like many tools in the data stack, dbt is limited by its own surface area and what it controls. One of the key benefits of the dbt MCP server is that it exposes the various types of metadata captured and curated in dbt.

However, dbt’s metadata, semantics, and hence, context stop at the dbt boundary. Lineage, governance, semantics, and business metadata don’t flow losslessly across tools.

That’s where a context layer is needed: one that can integrate with MCP servers and the APIs of a wide variety of tools, and provide a unified context for all the other tools in the data stack to consume.

Atlan provides the precise context layer you need to get the most out of an agentic data stack. For instance, teams using Atlan’s Context Engineering Studio can complement the dbt MCP server context with governance context, ownership metadata, and policy signals on top of the dbt metric definitions.

How does Atlan extend the dbt semantic layer for AI agents?

Atlan has been involved in the evolution of the dbt Semantic Layer, as it was one of the few launch partners of the dbt Semantic Layer back in 2022. Since then, AI agents have become mainstream, and so have agentic data stacks and MCP servers.

The following features of Atlan are centered on providing better integration with dbt to get the most out of not just the Semantic Layer but also SQL tools, Metadata Discovery, among others:

• Organization-wide metadata collection: Atlan gathers metadata across your full data estate, and turns it into real, viable, and useful context that agents can query.

• AI-native knowledge graph: An AI-native knowledge graph that connects all assets, glossary, metrics, and reports into a unified context layer for agents.

• Cross-system, column-level lineage: Fine-grained data lineage tracks data flow across the various ingestion, transformation, and BI tools in your data stack.

• Common vocabulary and ontology: A shared business glossary and ontology covers metrics and reports beyond what MetricFlow alone can support.

• Trust signals in datasets and metrics: Atlan embeds trust signals in datasets and metrics to give quality and reliable context to agents.

• Bi-directional sync with dbt: Atlan offers a bi-directional sync with dbt to sync tags, owners, lineage, descriptions, classifications, glossary, etc. Changes in either system propagate without manual reconciliation.

Many of the features that make up the context layer are rooted in Atlan’s data governance capabilities, for which it has been recognized as a Leader in the 2026 Gartner Magic Quadrant for Data & Analytics Governance Platforms.

Moving forward with MCP server for dbt

In the ETL/ELT processes, the most significant is the T, the transformation process, which dbt addresses. The transformation code contains the most important business logic, rules, and conditions for your organization’s data.

This transformation logic is absolutely crucial for ensuring accurate metrics, reports, and dashboards, and that data is available to users via APIs and the dbt MCP server. The MCP server allows AI agents to get access to the metadata via various toolsets for the Semantic Layer, Metadata Discovery, SQL, among other things.

What’s missing, though, is the context from everything that doesn’t live within dbt, as dbt’s context stops at dbt’s perimeter. That’s where Atlan comes in.

Atlan’s context layer is an AI knowledge graph-powered accumulation and organization of lineage, governance, metrics, and quality metadata across your data stack. It turns fragmented, siloed metadata into a single, unified context layer available to any and every AI agent in your data and AI stack.

FAQs about MCP server for dbt

1. How does the dbt MCP server work?

The dbt MCP server exposes dbt-specific tools for the Semantic Layer, Metadata Discovery, and SQL tools. These tools are helpful both for agentic workflows in other tools and also for human users developing dbt code directly on the dbt platform or using platforms like Databricks and Snowflake.

2. What permissions are required for agents to work with the dbt MCP server?

When you’ve configured agents to use Service Tokens, three permissions are required: Semantic Layer Only, Metadata Only, and Developer, whereas when you use PATs, the token inherits the requesting user’s permissions. When you set up the Semantic Layer initially, you will need Account Admin permissions.

3. What’s the difference between a local and a remote dbt MCP server?

The remote dbt MCP server is hosted at a dbt Labs endpoint. Six of the eight toolsets (except Codegen and CLI) are available for the remote dbt MCP server to use. It’s the type of MCP server you need to integrate with agents for external tools for BI, governance, lineage, cataloging, and analytics. The local dbt MCP server is built more for local testing and development.

4. Can the dbt MCP server work with the Atlan MCP?

Yes, dbt MCP server exposes the Semantic Layer, Metadata Discovery, and other toolsets for the Atlan MCP server to access. Atlan’s MCP server can retrieve relevant metadata for context and metric definitions, enabling search, discovery, cataloging, lineage, and governance, among other things.

5. Does the dbt MCP server for the Semantic Layer work with dbt Core?

No, to use the Semantic Layer and the related toolset, you need a dbt platform account with a production environment. That said, you can use other features with dbt Core without having a dbt platform account, such as the dbt CLI and Codegen tools.