Skip to main content
Glama
dbt-labs
by dbt-labs

parse

Parse and validate dbt project contents for Jinja or YAML syntax errors, generating a detailed artifact with timing insights for large project analysis.

Instructions

The dbt parse command parses and validates the contents of your dbt project. If your project contains Jinja or YAML syntax errors, the command will fail.

It will also produce an artifact with detailed timing information, which is useful to understand parsing times for large projects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Handler function for the 'parse' MCP tool. Executes the dbt parse command using the shared _run_dbt_command helper.
    def parse() -> str:
        return _run_dbt_command(["parse"])
  • Registration of the 'parse' tool via ToolDefinition, specifying the handler function, description from prompts, and annotations for tool behavior.
    ToolDefinition(
        fn=parse,
        description=get_prompt("dbt_cli/parse"),
        annotations=create_tool_annotations(
            title="dbt parse",
            read_only_hint=True,
            destructive_hint=False,
            idempotent_hint=True,
        ),
    ),
  • Shared helper function used by all dbt CLI tools, including 'parse', to execute dbt commands as subprocesses with proper flags, timeouts, and output handling.
    def _run_dbt_command(
        command: list[str],
        selector: str | None = None,
        resource_type: list[str] | None = None,
        is_selectable: bool = False,
        is_full_refresh: bool | None = False,
        vars: str | None = None,
    ) -> str:
        try:
            # Commands that should always be quiet to reduce output verbosity
            verbose_commands = [
                "build",
                "compile",
                "docs",
                "parse",
                "run",
                "test",
                "list",
            ]
    
            if is_full_refresh is True:
                command.append("--full-refresh")
    
            if vars and isinstance(vars, str):
                command.extend(["--vars", vars])
    
            if selector:
                selector_params = str(selector).split(" ")
                command.extend(["--select"] + selector_params)
    
            if isinstance(resource_type, Iterable):
                command.extend(["--resource-type"] + resource_type)
    
            full_command = command.copy()
            # Add --quiet flag to specific commands to reduce context window usage
            if len(full_command) > 0 and full_command[0] in verbose_commands:
                main_command = full_command[0]
                command_args = full_command[1:] if len(full_command) > 1 else []
                full_command = [main_command, "--quiet", *command_args]
    
            # We change the path only if this is an absolute path, otherwise we can have
            # problems with relative paths applied multiple times as DBT_PROJECT_DIR
            # is applied to dbt Core and Fusion as well (but not the dbt Cloud CLI)
            cwd_path = config.project_dir if os.path.isabs(config.project_dir) else None
    
            # Add appropriate color disable flag based on binary type
            color_flag = get_color_disable_flag(config.binary_type)
            args = [config.dbt_path, color_flag, *full_command]
    
            process = subprocess.Popen(
                args=args,
                cwd=cwd_path,
                stdout=subprocess.PIPE,
                stderr=subprocess.STDOUT,
                stdin=subprocess.DEVNULL,
                text=True,
            )
            output, _ = process.communicate(timeout=config.dbt_cli_timeout)
            return output or "OK"
        except subprocess.TimeoutExpired:
            return "Timeout: dbt command took too long to complete." + (
                " Try using a specific selector to narrow down the results."
                if is_selectable
                else ""
            )
    
    def build(
  • Top-level registration function that adds the dbt CLI tools, including 'parse', to the FastMCP server instance.
    def register_dbt_cli_tools(
        dbt_mcp: FastMCP,
        config: DbtCliConfig,
        *,
        disabled_tools: set[ToolName],
        enabled_tools: set[ToolName],
        enabled_toolsets: set[Toolset],
        disabled_toolsets: set[Toolset],
    ) -> None:
        register_tools(
            dbt_mcp,
            tool_definitions=create_dbt_cli_tool_definitions(config),
            disabled_tools=disabled_tools,
            enabled_tools=enabled_tools,
            enabled_toolsets=enabled_toolsets,
            disabled_toolsets=disabled_toolsets,
        )
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.

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

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

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

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