DBT Core MCP Server

by NiclasOlofsson

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.7.1
Disambiguation5/5
Each tool has a clearly distinct purpose. Overlaps like get_lineage vs get_column_lineage and build_models vs run_models are complementary, not ambiguous. Descriptions are detailed and steer the agent to the correct tool.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., analyze_impact, get_lineage, run_models). No mixing of styles or unconventional naming.
Tool Count5/5
14 tools is well-scoped for a dbt project management server. It covers all major operations without being excessive. Each tool has a clear justification.
Completeness5/5
The tool set covers the full lifecycle: project info, resource listing, building (models, seeds, snapshots, tests), dependency analysis (lineage, impact), database querying, and package installation. No significant gaps for common dbt workflows.
Average 4.6/5 across 14 of 14 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions running `dbt debug` for diagnostics, adding behavioral context beyond the schema. However, it doesn't disclose potential side effects, failure modes, or required permissions. With no annotations, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with internal implementation details (like ctx and state) that are not useful for tool users. The core purpose is stated concisely, but the extra boilerplate reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and an output schema (stated in context), the description covers the essential purpose and parameter behavior. It lacks detail on what specific information is returned but is otherwise complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description provides essential semantics for the single parameter run_debug, explaining its function and default. This compensates well for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves dbt project information with optional diagnostics, and the name aligns with this purpose. However, it does not differentiate from sibling tools like get_resource_info, which might cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_resource_info for specific resources). It only implies diagnostic use via the run_debug parameter but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action ('Render') without explaining side effects, authentication needs, or what the output represents (though an output schema exists). This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action and resource. Every word is necessary and there is no extraneous information.
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?
Given the tool's low complexity (no parameters, simple purpose) and the presence of an output schema, the description suffices. It tells the agent exactly what action to take and on which resource.
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?
The tool has zero parameters, and the schema coverage is 100% (trivially). The description adds no parameter information, but none is needed. The baseline score for 0 parameters is 4, and perfect clarity warrants a 5.
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?
The description clearly states the tool's action ('Render the demo UI resource') and specifies the exact resource path, making its purpose unambiguous. It also distinguishes itself from sibling tools that deal with data analysis, database queries, and model management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied by the tool's name and description (rendering a demo UI), but no exclusions or comparison with siblings are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the mechanism: dbt compares source data, identifies changes, inserts new rows with validity timestamps, and closes original rows. This gives good behavioral insight, but could also mention idempotency or side effects like potential data duplication on reruns.
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 sections: intro, 'When to use', 'How it works', Args, Returns, and Examples. Front-loaded with purpose. While slightly lengthy, every section adds value. Could be slightly more concise in the 'How it works' explanation, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and low schema coverage, the description provides sufficient context: usage guidelines, mechanism, parameter explanations, and examples. Output schema exists, so the brief return description is adequate. It covers the essential aspects for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description compensates by explaining 'select' as dbt selector syntax with examples (e.g., 'snapshot_name', 'tag:daily') and 'exclude' as 'Exclude specific snapshots'. Examples further clarify usage. The description 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?
The description clearly states it 'snapshot models' and 'capture historical changes - SCD Type 2', with a detailed explanation of tracking slowly changing dimensions. This effectively distinguishes it from siblings like 'run_models' or 'build_models' which handle regular model execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a 'When to use' section that specifies 'to track changes in slowly changing dimensions (SCD Type 2)'. It does not explicitly say when not to use or mention alternatives, but the context of sibling tool names provides implied differentiation. Additional exclusions would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description details auto-detection, multiple match handling, error raising (ValueError), and depth limits. Does not mention read-only nature or auth, but these are implied. Sufficient behavioral context for safe use.
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 Args, Returns, Raises, Examples sections. Some redundancy (e.g., repeating parameter names), but front-loaded with core purpose. Slightly long but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, all parameters, return behavior (lineage info with stats, multiple matches), and errors. Output schema exists for return details, so omission is acceptable. Lacks pagination or performance notes, but complete for typical use.
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 coverage is 0%, so description fully compensates: explains each parameter with examples, default values, and valid options (e.g., source naming format, direction options, depth meaning). Adds significant value beyond 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?
Description states 'Get lineage (dependency tree) for any dbt resource with auto-detection' – specific verb, resource, and scope. Clearly distinguishes from siblings like 'get_column_lineage' by focusing on resource-level, not column-level lineage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (dependency queries), naming conventions for sources, and examples. However, lacks explicit guidance on when NOT to use or alternatives (e.g., use get_column_lineage for column lineage). Still clear overall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool is for listing resources, returns simplified info for LLM consumption, and explains the default behavior and package discovery. It implies a read operation but does not explicitly state it is read-only or mention any prerequisites.
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?
The description is structured with clear sections (Args, Returns, Package Discovery, Examples) and is front-loaded with the purpose. While comprehensive, it is slightly lengthy but justifiable given the need to cover package discovery and examples.
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?
Given an optional output schema (mentioned but not detailed), the description covers parameter usage, return structure, examples, and special package discovery use case. It is complete for a list tool and fits well with sibling tools.
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?
There is one parameter with 0% schema coverage. The description compensates fully by listing all possible enum values with explanations, default behavior, and usage examples, making the parameter's meaning and usage very clear.
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?
The description clearly states 'List all resources' with optional filtering by type, using a specific verb and resource. It distinguishes from siblings like 'get_resource_info' by indicating it returns a list of all resources rather than details on a single resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use filtering and provides examples for each resource_type. It also includes a section on package discovery with specific use cases. However, it does not explicitly mention when not to use this tool or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: auto-detection of resource type, return of multiple matches with a special structure, side effects of include_compiled_sql (triggers dbt compile), and error raising (ValueError). It also notes the state parameter injection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for main description, args, returns, and raises. It is front-loaded with the core purpose. Every sentence adds value without redundancy, making it appropriately concise for a 4-parameter tool.
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?
Given the output schema exists, the description provides sufficient context about the return value (resource info dict, multiple matches handling). All parameters are thoroughly explained. The description is complete for the tool's complexity.
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?
The input schema has 0% description coverage, so the description carries the full burden. It provides detailed explanations for each parameter: name format for sources, resource_type values with descriptions, boolean parameters with their effects (including side effects like triggering compile). This adds significant meaning beyond the 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?
The description clearly states the tool's purpose: 'Get detailed information about any dbt resource (model, source, seed, snapshot, test, etc.)'. It is a specific verb-resource combination and distinguishes itself from sibling tools like list_resources (listing) or get_lineage (lineage) by focusing on detailed information retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context (e.g., source naming convention) but does not explicitly state when to use this tool versus alternatives. It implies it's for detailed resource info, but no when-not or exclusion criteria are given relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behavioral aspects: it is interactive, not infrastructure automation, and returns installation results. It could be more explicit about side effects like network access or file system changes, but overall provides good transparency.
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?
The description is well-structured with clear sections, but it is somewhat lengthy for a no-parameter tool. The example workflow is helpful but could be more concise. Still, every section adds value.
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?
Given the tool has no parameters and an output schema exists, the description is complete. It explains the workflow, when to use, and even provides an example. No gaps in context for an AI agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so the description does not need to add parameter details. Baseline is 4 for zero parameters, and the description provides context about what the tool operates on (packages.yml) without needing parameter specifics.
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?
The description clearly states 'Install dbt packages defined in packages.yml' with a specific verb and resource. It distinguishes from sibling tools like build_models and load_seeds by focusing on dependency installation.
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?
Explicit 'When to use' bullets: after modifying packages.yml, before using external macros, when setting up a new project. It also provides an alternative workflow using list_resources for verification, giving clear context for when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that the tool parses compiled SQL, tracks columns through CTEs, JOINs, etc., and raises ValueError or RuntimeError for specific conditions. It also notes the need for sqlglot and compiled models.
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?
The description is well-structured with sections for Args, Returns, Raises, Examples, and Note. It is front-loaded with the purpose. However, it is somewhat lengthy and could be more concise, especially the detailed return description, but it earns its place given the complexity.
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?
Given the complexity of column-level lineage, the output schema exists, and the description covers inputs, outputs, error handling, dependencies, and prerequisites. Examples are provided. The tool is fully described for an AI agent to use correctly.
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%, but the description thoroughly explains each parameter: model_name, column_name, direction (with three options and meanings), depth (with examples like depth=1, depth=2, None). It also details the return structure, adding significant meaning beyond the 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?
The description clearly states the tool traces column-level lineage through SQL transformations using sqlglot. It specifies the verb 'trace' and resource 'column-level lineage', and distinguishes it from siblings like 'get_lineage' which likely handles model-level lineage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to trace column dependencies) and includes prerequisites (sqlglot, compiled model). It gives parameter explanations and examples, but does not explicitly compare to sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: it shows downstream dependencies, provides recommendations, returns all matches for LLM to process if multiple found, raises ValueError, and explains resource_type filtering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises, Examples) and no wasted words. It is appropriately sized for the complexity of the tool.
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?
Given the output schema exists and the description explains the return structure in detail, the description is fully complete for an impact analysis tool.
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 coverage is 0%, so the description carries full burden. It provides detailed parameter semantics: name format (with source_name.table_name examples) and resource_type options with descriptions, adding significant meaning beyond the 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?
The description clearly states the tool analyzes the impact of changing dbt resources with auto-detection, and it distinguishes from sibling tools like get_lineage or get_resource_info by focusing on downstream dependencies and actionable recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (when changing dbt resources) and provides examples, but it does not explicitly mention when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: SQL execution with Jinja compilation, output formats, file saving with automatic directory creation, error raising (RuntimeError, ValueError), and elapsed time reporting. It also mentions memory considerations for large result sets.
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?
The description is well-structured with sections, bullet points, and examples, making it easy to parse. However, the CTE section contains some repetition across examples and notes; a slightly more condensed version would improve conciseness.
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?
Given the tool's complexity (5 params, no schema descriptions, no annotations, but output schema detailed), the description covers all necessary aspects: purpose, usage, parameters, return formats, error handling, and examples. It is complete and leaves no ambiguity.
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?
Despite 0% schema description coverage, the description thoroughly explains all 5 parameters: sql (templating rules), output_file (path handling, inline vs file), output_format (json/csv/tsv), cte_name and model_name (relation and usage with __cte__ placeholder). It adds meaning beyond the schema by detailing behavior and constraints.
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?
The description clearly states the tool's purpose: 'Execute a SQL query against the dbt project's database.' It distinguishes itself from sibling tools (e.g., analyze_impact, build_models) by being the only tool for direct SQL execution with Jinja templating support.
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?
The description provides comprehensive usage guidelines including when to use output_file for large results, when to include LIMIT, and how to use CTE parameters. It includes examples of correct and incorrect usage, and explicitly warns against invalid syntax like {{ ref('model', cte='name') }}.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explains the execution order (seeds, models, tests, snapshots), state-based selection mechanics, and return values. It discloses all relevant behavioral traits without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (overview, when to use, how it works, args, returns, see also, examples). Every sentence adds value, and the length is appropriate for the tool's complexity.
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?
The description covers purpose, usage, parameters, behavior, return info, and provides multiple examples. Given 7 parameters and no annotations, it is fully complete and leaves no gaps for an agent.
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%, but the description explains each parameter in detail with examples (e.g., 'select: dbt selector syntax (e.g., "customers", "tag:mart", "stg_*")'). It adds significant meaning beyond the schema names.
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?
The description clearly states 'Run dbt build (execute models and tests together in correct dependency order)' and differentiates from siblings like run_models and test_models. It provides a specific verb+resource and scope.
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 states 'This is the recommended do everything command' and includes a 'See also' section listing alternative tools with their purposes. Examples cover full builds, incremental workflows, and specific selections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details state-based selection modes, file hash change detection, limitations for large seeds (>=1 MiB), and the effect of full_refresh. This fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and examples. Every sentence is informative without unnecessary verbosity. It earns its length by providing comprehensive guidance.
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?
Given no annotations and 0% schema description coverage, the description covers all necessary context: what seeds are, when to use, selection mechanisms, large file caveats, examples, and return value. It is complete for the tool's complexity.
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?
With 0% schema description coverage, the description explains all six parameters in detail, including select, exclude, select_state_modified, full_refresh, show, and state. It adds meaning beyond the schema's type/default information.
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?
The description clearly states the tool loads seed data (CSV files) into database tables. It distinguishes from siblings like run_models, build_models, test_models by explicitly noting seeds are CSV files and providing a 'See also' section with alternatives.
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?
Includes a 'When to use' section advising to run before building models or tests that depend on reference data. Also provides examples and mentions alternatives like run_models and build_models, giving clear context for when to use this tool vs. others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the transparency burden. It details selection modes (state-based vs manual), fail_fast behavior, keep_cte_tests for debugging, and even the format of unit test failure diffs, leaving no ambiguity about tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with sections (When to use, Important, Args, Returns, See also, Examples, Note). Every sentence adds value, and it front-loads the primary purpose. Despite length, it remains clear and avoids redundancy.
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?
Given the complexity (6 params, no annotations, high behavioral detail needed), the description covers all aspects: purpose, usage conditions, parameter semantics, return values, sibling tools, and examples. It is complete and self-contained.
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 coverage is 0%, so the description must compensate. It explains all 6 parameters: select and exclude as manual selectors, state-based flags with the 'Note:' on prerequisites, fail_fast, keep_cte_tests, and state object. Examples further clarify usage.
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?
The description clearly states 'Run dbt tests on models and sources' (specific verb+resource). It distinguishes from siblings like run_models (execution) and build_models (run+tests) through the 'See also' section and usage guidance.
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 states 'When to use: After running models to validate data quality.' Includes important precondition ('Ensure seeds and models are built') and references alternative tools (run_models, build_models, load_seeds).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dbt-core-mcp MCP server](https://glama.ai/mcp/servers/NiclasOlofsson/dbt-core-mcp/badges/card.svg)](https://glama.ai/mcp/servers/NiclasOlofsson/dbt-core-mcp)

Score Badge

Copy to your README.md:

[![dbt-core-mcp MCP server](https://glama.ai/mcp/servers/NiclasOlofsson/dbt-core-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NiclasOlofsson/dbt-core-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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