Connect Claude to dbt Cloud

List the projects in the account, with each one's id, name, repository, connection and state. This is the natural first call and the cheapest proof that the service token, the account id and the host all agree - which is why it is the connection test. The project id it returns is what list_jobs, list_runs and list_environments filter on.

List the jobs defined in the account, with each one's id, name, schedule, environment, dbt version and the commands it runs. Narrow by project_id or environment_id - an account with several projects returns everything otherwise. The job id here is what get_job and trigger_job_run take, and what list_runs filters on as job_definition_id. Note that a job's definition is what it is configured to do; whether it last succeeded is a question for list_runs.

Fetch one job by id, with its full definition: the steps it executes, its schedule, its environment, its threads and timeout, and its triggers. Ids come from list_jobs. Pass include_related with "most_recent_run" to get the job's definition and its last run in one call, which is usually what you actually wanted.

List runs, newest last unless you order otherwise. This is where "did the nightly job work" is answered. `status` is a number, not a word: 1 queued, 2 starting, 3 running, 10 success, 20 error, 30 cancelled. Narrow with job_definition_id for one job's history, or project_id for one project's. Pass order_by "-id" with a small limit to get the most recent runs first. Note that include_related here is narrower than on get_run and does not accept run_steps.

Fetch one run by id, with its status, timings, the commit it ran and what triggered it. Ids come from list_runs, or from the run trigger_job_run returned. include_related accepts trigger, job, environment, repository, run_steps, run_retries, used_repo_cache, repo_cache_restore, audit and debug_logs. For the per-command breakdown of a failure use get_run_steps, which asks for run_steps for you.

Fetch one run with its steps expanded: every dbt command the run executed, in order, with each one's status, timing and log output. This is the operation to reach for when a run failed and the question is which model broke. dbt has no route that lists a run's steps on their own - the only way to get them is GET on the run itself with run_steps requested, which is exactly what this does, so use it rather than trying to construct a steps URL. Its response is kept out of the audit log because dbt's step logs are raw stdout and routinely quote query text and error rows from the warehouse.

List the artifact paths a completed run produced - manifest.json, catalog.json, run_results.json and the compiled and run SQL for each model. dbt answers with an array of file paths, not the files themselves. Use it to find out what a run left behind and whether docs were generated. Only completed runs have artifacts.

List the environments in the account, with each one's id, name, type, dbt version, project and connection. Environments are where jobs run, so this is how you tell a production environment's id from a staging one before filtering jobs or runs by it. This is the v2 account-wide listing; dbt's v3 API lists environments per project instead and returns more fields, which this connector does not use because everything else here is v2.