Skip to main content
Glama
NiclasOlofsson

DBT Core MCP Server

run_models

Execute dbt models to compile SQL and run transformations against your database, updating tables and views with selective or state-based runs.

Instructions

Run dbt models (compile SQL and execute against database).

What are models: SQL files (.sql) containing SELECT statements that define data transformations. Models are compiled and executed to create/update tables and views in your database.

Important: This tool runs models only (SQL files). For CSV seed files, use load_seeds(). For running everything together (seeds + models + tests), use build_models().

State-based selection modes (uses dbt state:modified selector):

  • select_state_modified: Run only models modified since last successful run (state:modified)

  • select_state_modified_plus_downstream: Run modified + downstream dependencies (state:modified+) Note: Requires select_state_modified=True

Manual selection (alternative to state-based):

  • select: dbt selector syntax (e.g., "customers", "tag:mart", "stg_*")

  • exclude: Exclude specific models

Args: select: Manual selector (e.g., "customers", "tag:mart", "path:marts/*") exclude: Exclude selector (e.g., "tag:deprecated") select_state_modified: Use state:modified selector (changed models only) select_state_modified_plus_downstream: Extend to state:modified+ (changed + downstream) full_refresh: Force full refresh of incremental models fail_fast: Stop execution on first failure check_schema_changes: Detect schema changes and recommend downstream runs cache_selected_only: Only cache schemas for selected models (default True for performance) state: Shared state object injected by FastMCP

Returns: Execution results with status, models run, timing info, and optional schema_changes

See also: - seed_data(): Load CSV files (must run before models that reference them) - build_models(): Run models + tests together in DAG order - test_models(): Run tests after models complete

Examples: # Run a specific model run_models(select="customers")

# After loading seeds, run dependent models
seed_data()
run_models(select="stg_orders")

# Incremental: run only what changed
run_models(select_state_modified=True)

# Run changed models + everything downstream
run_models(select_state_modified=True, select_state_modified_plus_downstream=True)

# Full refresh marts (rebuild from scratch)
run_models(select="tag:mart", full_refresh=True)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
selectNo
excludeNo
select_state_modifiedNo
select_state_modified_plus_downstreamNo
full_refreshNo
fail_fastNo
check_schema_changesNo
cache_selected_onlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries full burden. It details the execution behavior (compile SQL, execute against database), explains state-based modification detection, full refresh, fail fast, schema change detection, and caching. Lacks explicit idempotency info but is highly transparent overall.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (header, what are models, important notes, selection modes, args, returns, see also, examples). While lengthy, every section adds value and is organized logically. Slightly long but earns its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all aspects: purpose, usage guidance, parameter details, return values (even without output schema), sibling tool references, and multiple examples including state-based and manual scenarios. Comprehensive for a complex tool with 8 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides thorough explanations for all 8 parameters in the Args section, including default behaviors and relationships (e.g., state-based modes require select_state_modified=True). Adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Run dbt models (compile SQL and execute against database)' and explains what models are. Distinguishes from siblings by specifying that for CSV seeds use load_seeds() and for everything together use build_models().

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use this tool (only for models) and when not to (seeds: use load_seeds, all together: build_models). Covers state-based vs manual selection with detailed descriptions and examples.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NiclasOlofsson/dbt-core-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server