Skip to main content
Glama
Coalesce-Software-Inc

coalesce-transform-mcp

Official

COA Dry Run Create (DDL preview)

coa_dry_run_create
Read-onlyIdempotent

Preview DDL changes from coa create offline without warehouse access. Validate SQL generation and detect errors in node templates before running.

Instructions

Preview the DDL that coa create would execute, without hitting the warehouse. Forces --dry-run --verbose.

Runs entirely offline against local project files — no Coalesce cloud authentication or API calls. coa create (and coa run) are the offline local-dev commands; do not confuse with the scheduler-aware coa deploy / coa plan / coa refresh which target cloud environments.

OUTPUT SHAPE (CD-16959+): dry-run reports pass/fail for every selected node rather than stopping at the first template error. Scan the full stdout — a non-zero exit code means one or more nodes failed, but successful nodes still render their generated SQL above/below the failures. Do not assume early output implies all-clear.

Check the stdout: table names should resolve (not blank), column types should not be UNKNOWN (indicates broken ref() targets), and SQL should look correct. For V2 nodes specifically, watch for CREATE TABLE ... AS SELECT WHERE 1=0 with zero columns — this means the SELECT has a parse error and the dry-run reports success despite producing broken DDL. See coalesce://context/sql-node-v2-policy.

LIMITATION: dry-run only exercises the SQL generator. It does NOT validate that referenced columns or types exist in the actual warehouse — a dry-run can succeed with column references that will fail at run-time with 'invalid identifier'. Use cortex or another Snowflake-capable MCP to confirm the schema when that matters.

Args:

  • projectPath (string, required)

  • workspace (string, optional)

  • include / exclude (string, optional): Node selector

Returns: { command, exitCode, stdout, stderr, coaVersion }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
excludeNoCOA node selector to exclude.
includeNoCOA node selector, e.g., '{ STG_ORDERS }' or '{ location: "SRC" }'. See `coa describe selectors`.
workspaceNoCOA workspace name from workspaces.yml. Defaults to 'dev'.
projectPathYesAbsolute or relative path to the COA project root (the directory containing data.yml).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jsonNo
stderrYes
stdoutYes
commandYes
exitCodeYes
timedOutYes
coaVersionYes
jsonParseErrorNo
preflightWarningsNo
Behavior5/5

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

While annotations indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds substantial behavioral context: it forces --dry-run --verbose, runs entirely offline without API calls, reports per-node pass/fail, explains non-zero exit code meaning, and warns about V2 node pitfalls and the limitation that it doesn't validate column existence. No contradiction with annotations.

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 lengthy but well-structured with sections (OUTPUT SHAPE, LIMITATION) and front-loads the core purpose. Some redundancy exists (e.g., dry-run explained twice), but the complexity warrants the detail. Slightly verbose but organized.

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 (dry-run with special output behavior and limitations), the description covers output shape, failure handling, V2 node bugs, and cross-tool comparisons. The output schema exists, so return values are not needed. Complete for an 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 coverage is 100%, but the description adds significant value: it explains `include`/`exclude` as node selectors with examples, mentions workspace defaults to 'dev', and provides context for the node selector syntax. This goes beyond the schema descriptions.

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 'Preview the DDL that `coa create` would execute, without hitting the warehouse.' It specifies the verb (preview), resource (DDL), and explicitly distinguishes from `coa create` and cloud commands. The purpose is unambiguous and differentiated from siblings.

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 explains when to use this tool (preview DDL offline) and explicitly warns against confusing it with scheduler-aware cloud commands like `coa deploy`/`coa plan`/`coa refresh`. It also clarifies that `coa create` and `coa run` are offline local-dev commands, providing clear context and exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Coalesce-Software-Inc/coalesce-transform-mcp'

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