# dbt-plan [Health: Active]

**Category:** 📊 Data Platforms  
**Repository:** https://github.com/PresentJay/dbt-plan  
**GitHub Stars:** 2  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/dbt-plan

## Description
Predicts the DDL a dbt change will execute, before you run it. Reads files, not the warehouse.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `uvx` (confidence: high):

```json
"mcpServers": {
  "dbt-plan": {
    "command": "uvx",
    "args": ["dbt-plan"]
  }
}
```

## Documentation

## What dbt-plan MCP server does

dbt-plan reviews compiled dbt SQL changes before they alter warehouse objects. It is designed for a pre-execution workflow similar to a Terraform plan: inspect the predicted effects, resolve risky findings, and only then run dbt.

The analysis focuses on schema and dependency impact. It identifies added and removed columns, evaluates whether those changes are safe for a model's materialization and `on_schema_change` setting, and reports configuration changes that alter those policies. It can also flag changes that an enforced contract would reject and compare explicit `CAST` types between revisions.

## How it works

The server reads files and compares compiled SQL from different revisions rather than connecting to, or inspecting, the live warehouse. The primary workflow is `dbt-plan check`, which reports the number of changed models, the detected dialect, baseline information, findings, and an overall review status.

For downstream analysis, dbt-plan resolves references against the project's own compiled schema. It can identify models that directly name a removed column, downstream models whose `SELECT *` output changes even when their own file was untouched, and tests whose fixtures depend on the removed field. `SELECT *` handling includes columns from CTEs in the same statement and follows `ref()` into the referenced model's compiled SQL.

Findings include evidence and affected files where available. The output can distinguish safe, warning, and destructive results, explain the source and affected models, show relevant materialization settings, and identify broken-reference cascades. Full findings and graph information are available in JSON output.

## Tools and capabilities

- Detect column additions and removals from compiled SQL differences.
- Assess schema-change risk using materialization and `on_schema_change` behavior.
- Trace downstream breakage caused by dropped columns.
- Inspect `SELECT *` dependencies and follow compiled `ref()` relationships.
- Report enforced-contract violations in either direction.
- Detect materialization and `on_schema_change` configuration changes.
- Compare explicit `CAST` types across revisions.
- Produce human-readable findings with supporting evidence and machine-readable JSON.

## Limitations and notes

The analysis is file-based, so it does not verify the live warehouse state or query warehouse metadata. SQL dialect support varies across Snowflake, BigQuery, Redshift, Postgres, and DuckDB; dialect-specific analysis limits apply.

Unreadable or unresolved compiled SQL can produce warnings and reduce the certainty of downstream analysis. External consumer coverage is unknown, while declared exposures are treated as consumers. The tool reports risks before policy separately from the exit policy, so a destructive finding may require review even when a separate command policy determines the process exit status.

_Full upstream README: https://allmcps.com/mcp/dbt-plan/readme_