search_dbt_node_namesLABSCO SUMMARY
Column lineage is the part nothing else gives you cheaply.
Model-level dependencies are already in the dbt docs site. Tracing one column back to its sources, or forward to everything that would break, is the question that actually stops a refactor — and it is precomputed here rather than derived per query. Budget for that precompute: the README says it can run for hours on a large project, and it has to be rerun when the project changes.
What it is
A server over dbt Docs artifacts. It loads your project's manifest and catalog and answers structural questions about models, sources and tests, including which upstream column a given column actually comes from.
What you get
- search_dbt_node_names finds nodes by name; search_dbt_column_names locates nodes by column; search_dbt_sql_code searches inside compiled SQL
- get_dbt_node_attributes returns the full detail for a node's unique id
- get_dbt_predecessors and get_dbt_successors return direct upstream dependencies and direct downstream dependents
- get_column_ancestors traces every upstream source of a specific column, and get_column_descendants traces everything downstream of it
- Column-level lineage is precomputed by a bundled script from your manifest and catalog, so queries are lookups rather than parses
Requirements
Python and uv, run from a checkout. MANIFEST_PATH points at your dbt manifest.json. Column-level lineage is optional and prepared ahead of time with scripts/create_manifest_cl.py, which writes the schema mapping and column-lineage files named by SCHEMA_MAPPING_PATH and MANIFEST_CL_PATH — on a large project that step can take hours.
Setup effort
Build from source — git clone https://github.com/mattijsdp/dbt-docs-mcp
USE CASES
01
Finding the model behind a column
Search by column name rather than guessing which model owns it.
02
Judging whether a change is safe
Direct dependents, then everything downstream of the specific column you are touching.
03
Explaining where a number comes from
Column ancestors trace the value back through the transformations to its sources.
04
Finding where a pattern appears in the SQL
Search compiled SQL across the project rather than grepping model files.
8 tools
Listed in project docs. Your client may show a different list.
search_dbt_column_namessearch_dbt_sql_codeget_dbt_node_attributesget_dbt_predecessorsget_dbt_successorsget_column_ancestorsget_column_descendantsBEFORE YOU INSTALL
What to know first
Tools you get
8 tools named in the project's documentation.
Requires
- Python
- uv
Where it runs
Both documented clients run the server on your machine.
INSTALLATION
Connect your client
You clone this one yourself.
Server setup
TERMINAL
git clone https://github.com/mattijsdp/dbt-docs-mcp
cd dbt-docs-mcpMCP Clients
Claude Desktop, Cursor
JSON
{
"mcpServers": {
"DBT Docs MCP": {
"command": "uv",
"args": [
"run",
"--with",
"networkx,mcp[cli],rapidfuzz,dbt-core,python-decouple,sqlglot,tqdm",
"mcp",
"run",
"<YOUR_PATH_TO_CLONE>/src/mcp_server.py"
],
"env": {
"MANIFEST_PATH": "<YOUR_MANIFEST_PATH>",
"SCHEMA_MAPPING_PATH": "DESIRED_OUTPUT_PATH_FOR_SCHEMA_MAPPING",
"MANIFEST_CL_PATH": "DESIRED_OUTPUT_PATH_FOR_MANIFEST_CL"
}
}
}
}<YOUR_PATH_TO_CLONE> is the absolute path of your clone, and <YOUR_MANIFEST_PATH> is your dbt manifest.json. The other two paths are for column-level lineage: create those files first with uv sync, then python scripts/create_manifest_cl.py (it can take hours on a large project).
