dbt Cloud + clariBI
Connect dbt Cloud through clariBI's MCP catalog. Read-only OAuth on the Semantic Layer, model lineage, freshness, and job runs — analyses use your data team's canonical metric definitions instead of re-deriving them.
Native dbt Cloud connector via the MCP catalog.
Connect with OAuth + DCR on your account-specific dbt endpoint. Ask any "what is our MRR / ARR / churn" question and the AI engine calls the dbt Semantic Layer directly — same metric definition your data team publishes, not a re-derived approximation. dbt Cloud Enterprise and Enterprise+ accounts.
What is dbt Cloud?
dbt Cloud is where many data teams define the canonical metrics, models, and lineage the rest of the business reports against. Its Semantic Layer turns "what is MRR?" disputes into a single source of truth.
clariBI reaches your dbt project through the official remote dbt MCP server: the Semantic Layer (metrics, dimensions, entities, saved queries), Discovery (model lineage, freshness, test results, exposures), and Admin API reads (job/run details). The integration is read-only at the catalog layer — write CLI tools (build, run, test, trigger_job_run, retry_job_run) and direct SQL execution are filtered out and never reachable through clariBI.
Learn more at getdbt.com
Connect dbt Cloud in three steps
Copy your dbt MCP endpoint URL
In dbt Cloud, go to Account settings → Access URLs → MCP Endpoint URL. The URL is account-specific (multi-cell accounts use a per-account prefix). Copy it.
Paste in clariBI and authorize
In clariBI Data Sources → MCP Servers, find dbt Cloud, paste your endpoint URL, and click Connect. A dbt OAuth popup opens with the Semantic Layer + Discovery read scopes pre-selected. Approve.
Ask questions, get dashboards
clariBI lists every dbt-defined metric and calls them via query_metrics. Ask "Show me monthly active users by signup channel last quarter" or "Is the fct_revenue model healthy and fresh?" — the answer matches what your data team publishes, with lineage and freshness checks included.
What you can analyze
Out of the box with the dbt Cloud MCP connector:
- Semantic Layer metrics (MRR, ARR, churn, MAU) by any defined dimension
- Model lineage and downstream-impact analysis
- Model health: latest run status, test results, upstream source freshness
- Pipeline-health dashboards (job runs, failures, durations, run history)
- Source-freshness audits across the project
- Exposure ownership and downstream dashboard / app dependencies
dbt Cloud is one of 60+ vendors in the clariBI MCP catalog. See the full list →
What the AI engine can call
The remote dbt MCP exposes ~60 tools across Semantic Layer, Discovery, CLI, and Admin API. clariBI curates ~40 read-only ones for the planner. Mutating CLI tools (build, run, test, trigger_job_run, retry_job_run) and ad-hoc execute_sql are filtered out at the catalog layer.
Semantic Layer (the gold path)
The dbt-defined metrics. clariBI calls these as canonical business metrics so "MRR" in the analysis matches "MRR" in your data team's source of truth.
Tools: list_metrics, query_metrics, get_dimensions, get_entities, get_metrics_compiled_sql, list_saved_queries
Discovery (lineage + health)
Model metadata, lineage, freshness, and test results. Lets clariBI answer "where does this number come from?" and "is this dashboard up to date?" with real provenance.
Tools: get_all_models, get_model_details, get_model_health, get_model_parents, get_model_children, get_lineage, get_all_sources, get_exposures, +15 more
Admin API reads (pipeline health)
Job + run metadata for ops dashboards. clariBI surfaces failed runs, run-duration trends, and artifact provenance without giving the planner the ability to trigger or cancel jobs.
Tools: list_projects, list_jobs, get_job_details, list_jobs_runs, get_job_run_details, get_job_run_error, list_job_run_artifacts
Product Docs + read-only CLI
Docs grounding plus read-only project introspection. Useful when the AI engine needs to explain a dbt concept or compile a model without executing it.
Tools: search_product_docs, get_product_doc_pages, list, parse, compile, docs, show
Cross-source questions dbt Cloud unlocks
The Semantic Layer is the contract between data engineering and the rest of the business. With dbt connected, clariBI uses your team-curated metric definitions as the canonical answer, then enriches with the operational data it materialises from Stripe, HubSpot, Plain, and the rest of the catalog.
dbt Semantic Layer × Stripe
"Show me dbt's MRR metric by signup channel for the last 12 months, and reconcile against Stripe's raw amount_paid totals."
Planner: list_metrics → query_metrics(mrr, dimension=signup_channel) → aggregate Stripe amount_paid for the same window → surface deltas and the dbt model line responsible for the calculation.
Pipeline health
"Which downstream exposures are at risk from the failed nightly run, and who owns them?"
Planner: list_jobs_runs(status=failed) → for each failed run, get_job_run_details → get_model_children for the affected models → get_exposure_details on downstream exposures.
Lineage-grounded answer
"Is the revenue dashboard's number fresh, and what models feed it?"
Planner: get_exposures → pick the revenue exposure → get_exposure_details → get_model_health on each parent → surface freshness + test status + last-run timestamp.
dbt Cloud connector FAQ
Which dbt Cloud plan do I need?
Remote MCP with OAuth is generally available on dbt Cloud Enterprise and Enterprise+ accounts. Lower-tier accounts can still connect via a Personal Access Token instead of OAuth.
Why does the connector ask for a per-account endpoint URL?
Multi-cell dbt Cloud accounts have an account-specific prefix (e.g. your-account.us1.dbt.com) instead of the default cloud.getdbt.com. You can find your URL in Account settings → Access URLs → MCP Endpoint URL. clariBI captures it per-connection.
Can clariBI run dbt jobs or trigger runs?
No. The dbt MCP exposes mutating CLI tools (build, run, test, clone) and admin actions (trigger_job_run, retry_job_run, cancel_job_run), but they're all excluded at the catalog layer. The planner only sees the read surface.
Does clariBI execute arbitrary SQL against my warehouse?
No. execute_sql is excluded from the tool allowlist because it requires a Personal Access Token plus environment-id setup that the catalog connection flow can't safely capture. Use query_metrics for canonical metrics or set up execute_sql as a dedicated integration when you need ad-hoc warehouse queries.
My metric returned 403 — why?
The connected user doesn't have permission for that metric or its underlying model. Either adjust the user's role in dbt or reconnect using a user with broader Semantic Layer + Discovery read access. Permission errors surface in the analysis as a clear "this metric is gated" message, not a silent empty result.
Start your free trial and connect dbt Cloud in a minute
OAuth in, read-only, dashboards in seconds.
Start free trial