dbt-mcp

Official

by dbt-labs

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is some overlap between 'build' and 'run' (both execute models), and 'compile' and 'parse' (both involve processing project files). Descriptions help clarify differences, but an agent might still confuse these pairs in certain contexts.
Naming Consistency2/5
Naming is inconsistent with mixed patterns: some use verb_noun (e.g., 'get_all_models', 'list_metrics'), others use single verbs (e.g., 'build', 'run', 'compile'), and some are noun-based (e.g., 'docs'). This lack of a uniform convention makes the set harder to navigate and predict.
Tool Count4/5
With 16 tools, the count is reasonable for a dbt server covering core operations, project management, and semantic layer queries. It's slightly on the higher side but well within an acceptable range for the domain's complexity.
Completeness5/5
The tool set comprehensively covers dbt functionality: core commands (build, run, test), project inspection (compile, parse, list), model details retrieval, and full semantic layer operations (list_metrics, query_metrics with supporting tools). No obvious gaps exist for typical dbt workflows.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 14 of 19 community issues answered or closed in the last 6 months
- 43 commits in the last 12 weeks
- Last stable release on July 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that entities are 'real-world concepts' and gives examples (customers, transactions, ad campaigns), but doesn't describe what the tool actually returns - whether it's metadata, identifiers, full objects, or something else. It doesn't address pagination, rate limits, authentication requirements, error conditions, or what happens with invalid metrics. The behavioral expectations are largely undefined.
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 reasonably concise with clear sectioning using <instructions> and <parameters> tags. The first sentence directly states the tool's purpose, and the entity definition is relevant context. However, the entity examples could be more targeted to this specific tool rather than generic business concepts. The structure is good but could be more front-loaded with critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't adequately explain what the tool returns, how entities relate to metrics, what format the response takes, or error handling. For a tool that presumably returns data based on metric inputs, the description leaves too many operational questions unanswered, especially considering the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 only states 'metrics: List of metric names' which repeats the parameter name without adding meaningful semantics. It doesn't explain what constitutes a valid metric name, where to find available metrics, whether there are constraints on the list size, or what happens if metrics don't exist. The description fails to provide the necessary parameter context that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get the entities for specified metrics' which provides a basic verb+resource combination. However, it's vague about what 'entities' actually are in this context - while it defines entities generically as 'real-world concepts in a business', it doesn't specify what type of entities this particular tool returns or how they relate to the metrics. The description distinguishes from some siblings (like 'list_metrics' or 'query_metrics') but not clearly from others like 'get_dimensions' or 'get_all_models'.
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?
The description provides no explicit guidance on when to use this tool versus alternatives. While it mentions that 'Analysis is often focused around specific entities', this is generic context rather than practical usage guidance. There's no mention of when to choose this tool over sibling tools like 'get_dimensions' or 'list_metrics', nor any prerequisites or constraints for its use.
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 carries the full burden of behavioral disclosure. The description states it 'Get the dimensions' which implies a read-only operation, but it doesn't specify whether this requires authentication, what format the output is in, if there are rate limits, or any error conditions. For a tool with no annotation coverage, this leaves significant behavioral gaps.
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 appropriately sized with clear sectioning using <instructions> and <parameters> tags. The first sentence directly states the purpose, and the explanation of dimensions is helpful context. However, the structure could be more front-loaded with the core purpose, and the parameters section is somewhat redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It doesn't explain what the tool returns, how dimensions are structured, or provide any examples. For a tool that presumably returns data about dimensions, the lack of output information is a significant gap, especially with multiple sibling tools that might overlap in functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a parameters section that lists 'metrics: List of metric names', which matches the single parameter in the input schema. However, with 0% schema description coverage, the description doesn't add meaningful semantics beyond what's obvious from the parameter name. It doesn't explain what valid metric names are, provide examples, or describe the relationship between metrics and dimensions. The baseline is 3 since schema coverage is low but the description provides minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get the dimensions for specified metrics' which provides a clear verb ('Get') and resource ('dimensions'), but it's somewhat vague about what dimensions actually are. The explanation 'Dimensions are the attributes, features, or characteristics that describe or categorize data' helps but doesn't make the purpose specific enough to distinguish it from siblings like 'get_entities' or 'list_metrics' without additional context.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_entities', 'list_metrics', and 'query_metrics' available, there's no indication of when this tool is appropriate or what distinguishes it from those other options. The only implied usage is when you need dimensions for metrics, but no explicit context or exclusions are provided.
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 carries the full burden of behavioral disclosure. It states the action but doesn't cover critical aspects like whether this is a read-only operation, potential errors, rate limits, or what the output format might be (e.g., list of parent names). This leaves significant gaps for an agent.
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, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently conveys the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a query tool with no annotations, 0% schema coverage, and no output schema), the description is incomplete. It doesn't address behavioral traits, parameter details, or output expectations, making it insufficient for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description doesn't add any parameter details beyond the schema's 'model_name'. It doesn't explain what a 'model_name' entails (e.g., format, examples, or constraints), failing to compensate for the low coverage.
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 the verb ('Get') and resource ('parents of a specific dbt model'), making the purpose understandable. However, it doesn't differentiate from siblings like 'get_all_models' or 'get_model_details' beyond the specific focus on parents, which is a minor gap.
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?
The description provides no guidance on when to use this tool versus alternatives such as 'get_all_models' or 'get_model_details'. It lacks context about prerequisites, exclusions, or comparisons to sibling tools, leaving usage unclear.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'lists' resources, implying a read-only operation, but doesn't specify whether this includes all resource types, if there's pagination, what the output format is, or any performance considerations. This is a significant gap for a tool with zero annotation coverage.
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 a single, clear sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'resources' encompass in a dbt project (e.g., models, sources, tests) or what the return value looks like, making it hard for an agent to use this tool effectively without additional context.
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 tool has 0 parameters, and the schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for this case is 4, as the description appropriately doesn't discuss parameters that don't exist.
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 the verb ('List') and resource ('resources in your dbt project'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_all_models', 'get_dimensions', or 'get_entities' which might also list specific resource types, leaving some ambiguity about scope.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_all_models' or 'get_entities'. It lacks context about what types of resources are included (e.g., models, tests, seeds) or any prerequisites, leaving the agent to guess based on tool names alone.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes the sequence of operations (run, test, snapshot, seed in DAG order) but lacks critical details: whether this is a read-only or destructive operation, permission requirements, execution time implications, error handling, or output format. For a complex multi-operation tool with zero annotation coverage, this is insufficient.
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 extremely concise and well-structured: a single introductory sentence followed by a bulleted list of four operations and a closing note about execution order. Every element adds value with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing four different operation types in sequence), absence of annotations, and no output schema, the description is incomplete. It explains what operations occur but not their behavioral implications, success/failure conditions, or what results to expect. For a build tool in a data transformation context, this leaves significant gaps.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't discuss parameters, maintaining focus on the tool's behavior. Baseline for 0 parameters is 4.
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 the tool executes multiple dbt operations (run models, test tests, snapshot snapshots, seed seeds) in DAG order. It specifies the verb 'command will' and the resources affected, but doesn't explicitly differentiate from siblings like 'run' or 'test' which might perform subsets of these operations.
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 is provided on when to use this tool versus alternatives like 'run', 'test', or 'seed'. The description lists what it does but doesn't indicate appropriate contexts, prerequisites, or exclusions compared to sibling tools.
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 carries the full burden of behavioral disclosure. It states the tool generates documentation but doesn't cover critical aspects like whether it's read-only or destructive, permission requirements, output format, or side effects (e.g., creating files). For a tool with zero annotation coverage, this leaves key behavioral traits unspecified.
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, efficient sentence that directly states the tool's function without any fluff. It's front-loaded with the core purpose ('generating your project's documentation website'), making it easy to parse. Every word earns its place, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely performs a significant action (generation). It doesn't explain what 'generating' entails (e.g., file creation, web server startup), potential dependencies, or error conditions. For a tool in a development context with many siblings, more context is needed to guide effective use.
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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately avoids redundant information and focuses on the tool's purpose without unnecessary parameter elaboration.
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 the tool's purpose: 'generating your project's documentation website.' It specifies the verb ('generating') and the resource ('documentation website'), making it understandable. However, it doesn't differentiate from sibling tools like 'build' or 'compile', which might have overlapping functions in a development context.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., after code changes), or exclusions, leaving the agent to infer usage from the purpose alone. With many sibling tools like 'build', 'compile', and 'run', this lack of differentiation is a significant gap.
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 carries full burden. It states the tool retrieves data ('Get'), implying a read-only operation, but lacks details on permissions, rate limits, pagination, or response format. For a tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
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, efficient sentence with zero waste. It front-loads the core purpose ('Get the name and description') and specifies the scope ('all dbt models in the environment'), making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a read operation with potential complexity (e.g., handling many models), the description is incomplete. It lacks information on return values, error handling, or behavioral traits like performance considerations. For a tool in this context, it should provide more completeness.
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 tool has 0 parameters, and schema description coverage is 100% (though empty). The description adds no parameter information, which is appropriate here. A baseline of 4 is given as no parameters exist, and the description doesn't need to compensate for any gaps.
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 the action ('Get') and resource ('all dbt models in the environment'), specifying what information is retrieved ('name and description'). It distinguishes from siblings like 'get_model_details' (likely more detailed) and 'get_mart_models' (likely filtered), though not explicitly. However, it lacks explicit sibling differentiation, preventing a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_mart_models' or 'get_model_details'. It implies usage for retrieving basic model metadata but offers no context on prerequisites, exclusions, or comparative scenarios with sibling tools.
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 carries the full burden of behavioral disclosure. It states that the tool 'runs' tests, implying a read-only or execution operation, but doesn't clarify if it's destructive (e.g., modifies data), requires specific permissions, has rate limits, or what the output entails (e.g., test results, logs). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action ('runs data tests') and specifies the scope clearly. Every part of the sentence contributes to understanding the purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It explains what the tool does (runs tests on dbt objects), but doesn't cover behavioral aspects like output format, error handling, or integration with siblings. For a simple execution tool, it meets the basic need but lacks depth for full contextual understanding.
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 with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention any parameters, which is appropriate since there are none. It adds no semantic details beyond the schema, but with zero parameters, the baseline is high as there's nothing to compensate for, and the description doesn't mislead about parameters.
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 the tool's purpose: 'runs data tests defined on models, sources, snapshots, and seeds and unit tests defined on SQL models.' It specifies the verb ('runs') and the resources (tests on various dbt objects), making it clear what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'run' or 'build', which might also involve execution, so it doesn't reach the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for testing (e.g., after building models), or comparisons to siblings like 'run' (which might execute models) or 'list' (which might list tests). Without such guidance, the agent lacks direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the command will fail on syntax errors and produces a timing artifact, which are useful behavioral traits. However, it doesn't mention whether this is a read-only operation, what permissions are required, or how it affects project state - important gaps for a tool that validates project contents.
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 appropriately concise with two focused paragraphs. The first sentence clearly states the core purpose, and the second adds valuable context about the timing artifact. No wasted words, though the structure could be slightly improved by combining related ideas more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 no output schema, the description provides adequate information about what the tool does and some behavioral aspects. However, for a validation/parsing tool with no annotations, it should ideally mention whether this is a safe read-only operation or if it modifies project state, and what the typical output/result looks like.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of parameters. The description appropriately doesn't discuss parameters, maintaining focus on what the tool does rather than how to configure it. This meets the baseline expectation for parameterless tools.
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 the tool's purpose: 'parses and validates the contents of your dbt project' and mentions it will fail on syntax errors. It distinguishes from siblings like 'build', 'run', or 'test' by focusing on parsing/validation rather than execution or testing. However, it doesn't explicitly contrast with 'compile' which might be similar.
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?
The description provides no guidance on when to use this tool versus alternatives like 'compile' or 'build'. It mentions the tool will fail on syntax errors, which implies it could be used for validation, but doesn't state when this is preferable to other validation approaches or how it relates to sibling tools.
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 carries the full burden of behavioral disclosure. It states the tool retrieves information (implying read-only), but does not address potential errors (e.g., if the model doesn't exist), performance considerations, authentication needs, or rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 well-structured with clear sections (<instructions> and <parameters>), front-loading the purpose in the first sentence. Every sentence earns its place by specifying the action, resource, returned data, and parameter meaning without any redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is adequate but incomplete. It clearly defines the purpose and parameter, but lacks details on error handling, return format (e.g., structure of the output), and behavioral traits like idempotency or side effects, which are important for a retrieval tool with no annotation support.
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 description coverage is 0%, so the description must compensate. It provides the parameter 'model_name' with a clear semantic explanation ('The name of the dbt model to retrieve details for'), which adds meaningful context beyond the schema's basic type and title. However, it does not specify format constraints (e.g., case sensitivity) or examples, leaving some ambiguity.
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 specific action ('Retrieves information') and resource ('specific dbt model'), distinguishing it from siblings like 'get_all_models' (which lists all models) and 'get_model_parents' (which focuses on dependencies). It explicitly lists the returned information: compiled SQL, description, column names, column descriptions, and column types.
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 implies usage by specifying it retrieves details for 'a specific dbt model', suggesting it should be used when detailed metadata about a single model is needed. However, it does not explicitly state when to use this tool versus alternatives like 'get_all_models' (for overviews) or 'docs' (for documentation), nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it performs write operations (executes SQL, materializes data models), connects to a database, and follows a dependency order. However, it lacks details on permissions needed, side effects (e.g., data overwriting), error handling, or runtime characteristics like timeouts.
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 and front-loaded with the core action in the first sentence. Each subsequent sentence adds valuable context about connectivity, materialization, and execution order without redundancy. It could be slightly more concise by combining some ideas, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a database execution tool with no annotations or output schema), the description is adequate but has gaps. It explains what the tool does and how it operates, but lacks details on outputs (e.g., success/failure indicators, logs), error conditions, or integration with sibling tools like 'test' or 'compile'. This is minimally viable for understanding but not fully comprehensive.
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 with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's action and context. This meets the baseline for tools with no parameters.
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 specific action ('executes compiled sql model files'), target ('against the current target database'), and mechanism ('using the specified materialization strategies'). It distinguishes from siblings like 'compile' (which prepares models) or 'test' (which validates them) by focusing on execution.
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 implies usage by describing the tool's function and order of operations ('Models are run in the order defined by the dependency graph'), but does not explicitly state when to use this tool versus alternatives like 'build' (which may combine run and test) or other siblings. No exclusions or prerequisites are mentioned.
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?
With no annotations provided, the description carries full burden but only partially discloses behavioral traits. It mentions the tool is 'useful for visually inspecting' and 'validating,' implying it's a read-only/safe operation, but doesn't clarify if it modifies any state, requires specific permissions, has side effects, or details about output format (though no output schema exists). More behavioral context is needed given the lack of annotations.
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 in two sentences: the first states the core purpose, and the second provides usage context. Every sentence adds value without redundancy, making it appropriately sized and front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (compiling SQL from multiple file types) and lack of annotations/output schema, the description is moderately complete. It explains the purpose and usage but lacks details on behavioral aspects like side effects, error handling, or output format. For a tool with no structured data support, more context would improve completeness.
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 with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on tool behavior rather than parameters, earning a high baseline score. It doesn't add parameter details beyond the schema, which is fine since there are none to document.
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 specific action ('generates executable SQL') and resources involved ('from source model, test, and analysis files'), distinguishing it from sibling tools like 'run' or 'test' that likely execute rather than compile. It provides a concrete verb+resource combination that leaves no ambiguity about the tool's function.
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 explicitly states when to use this tool: 'for visually inspecting the compiled output' and 'for validating complex jinja logic or macro usage.' However, it doesn't specify when NOT to use it or mention alternatives among the many sibling tools (like 'run' for execution or 'parse' for parsing), leaving some guidance gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool executes SQL and returns results, which is basic behavioral information. However, it doesn't mention important traits like whether this is read-only vs. potentially destructive, authentication needs, rate limits, error handling, or result format details.
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 perfectly concise with three sentences that each earn their place: states the core functionality, provides usage context, and explains a key parameter. It's front-loaded with the main purpose and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary SQL with 2 parameters and no output schema, the description is moderately complete. It covers the basic purpose and one parameter's semantics, but lacks details on result format, error conditions, or safety considerations (especially important for SQL execution tools). No annotations exist to fill these gaps.
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 description coverage is 0%, so the description must compensate. It explains the 'limit' parameter's purpose: 'Use the limit argument in place of a SQL `LIMIT` clause,' which adds valuable semantic context beyond the schema's basic type information. However, it doesn't explain the 'sql_query' parameter beyond what's obvious from the name.
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: 'executes an arbitrary SQL statement against the database and returns the results.' It specifies the verb (executes), resource (SQL statement), and outcome (returns results). This distinguishes it from siblings like 'query_metrics' or 'get_all_models' which have more specific scopes.
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: 'useful for debugging and inspecting data in your dbt project.' It implies when to use this tool (for debugging/inspecting) but doesn't explicitly state when not to use it or name specific alternatives among siblings like 'query_metrics' for metric queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's behavior as retrieving name and description for all mart models, which is straightforward for a read operation. However, it lacks details on potential limitations like pagination, rate limits, or authentication requirements, leaving gaps in behavioral disclosure.
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 in two sentences: the first states the tool's action and output, and the second provides essential context about mart models. Every sentence adds value without redundancy, making it front-loaded and appropriately sized for the tool's simplicity.
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's low complexity (0 parameters, no output schema, no annotations), the description is largely complete. It explains what the tool does and the context of mart models. However, without annotations or output schema, it could benefit from mentioning the return format (e.g., list of objects) to fully compensate for the lack of structured data.
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 with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and context, which aligns with the baseline expectation for tools without parameters.
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 specific action ('Get'), resource ('mart models'), and scope ('all mart models in the environment'). It distinguishes mart models from other dbt project components by explaining they are part of the presentation layer for end-user consumption, differentiating from sibling tools like get_all_models or get_dimensions.
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 about when to use this tool by defining what mart models are and their purpose in the dbt project. However, it does not explicitly mention when not to use it or name specific alternatives among the sibling tools, such as get_all_models for broader scope or get_model_details for deeper information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's purpose and usage context well but lacks details on behavioral traits like rate limits, authentication requirements, pagination, or error handling. The description doesn't contradict any annotations, but it doesn't fully compensate for the lack of structured metadata.
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 a clear purpose statement, usage guidelines, and examples in three concise sentences. Every sentence adds value without redundancy, and it's front-loaded with the core functionality.
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's simplicity (0 parameters, no output schema), the description provides good contextual completeness by explaining its role in workflows and including examples. However, without annotations or output schema, it could benefit from more details on return format or limitations, though this is less critical for a list operation.
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 tool has 0 parameters, and schema description coverage is 100%. The description appropriately doesn't discuss parameters, as none exist. It focuses on the tool's purpose and usage instead, which is sufficient for a parameterless tool.
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 specific action ('List all metrics') and resource ('from the dbt Semantic Layer'), distinguishing it from sibling tools like 'get_dimensions', 'get_entities', or 'query_metrics'. It precisely defines what the tool does without being vague or tautological.
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 explicitly states when to use this tool ('as a first step to get a list of metrics that can be used with other tools to answer the question') and provides concrete examples of user questions that would trigger its use. This gives clear guidance on its role in a workflow compared 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?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It describes prerequisites (must know specific metrics/dimensions/entities), constraints (order_by requires group_by inclusion), best practices (two-step approach for large data sets), syntax requirements (database-agnostic SQL with specific templating), and date format restrictions. It also explains what constitutes a valid lookback query.
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 (instructions, examples, parameters) but is quite lengthy. While every sentence adds value, the extensive examples section could be more concise. The core instructions are front-loaded and efficiently written, but the overall length might be excessive for some use cases.
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 the tool (5 parameters, 0% schema coverage, no annotations, no output schema), the description provides complete contextual information. It covers prerequisites, parameter usage, constraints, best practices, error cases, and provides multiple detailed examples. The description fully compensates for the lack of structured metadata and prepares an agent to use the tool effectively.
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 fully compensates by providing rich semantic context for all parameters. It explains what 'metrics' should contain, how 'group_by' works with dimensions and entities, the relationship between 'order_by' and 'group_by', specific syntax for the 'where' parameter including templating requirements, and guidance on using 'limit' for verification queries. The examples demonstrate practical parameter 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 the tool's purpose: 'Queries the dbt Semantic Layer to answer business questions from the data warehouse.' It specifies the action (queries), target (dbt Semantic Layer), and outcome (answer business questions). It also distinguishes from siblings by mentioning specific prerequisite tools (list_metrics, get_dimensions, get_entities) that must be called first.
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 explicit guidance on when to use this tool versus alternatives. It states: 'Don't call this tool if the user's question cannot be answered with the provided metrics, dimensions, and entities. Instead, clarify what metrics, dimensions, and entities are available and suggest a new question.' It also provides detailed examples of when to use it for different types of business questions.
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-mcp MCP server](https://glama.ai/mcp/servers/dbt-labs/dbt-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dbt-labs/dbt-mcp)

Score Badge

Copy to your README.md:

[![dbt-mcp MCP server](https://glama.ai/mcp/servers/dbt-labs/dbt-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dbt-labs/dbt-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/dbt-labs/dbt-mcp'

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