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.
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.
- 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
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.
One command — uvx dbt-docs-mcp