Skip to main content
Glama
Coalesce-Software-Inc

coalesce-transform-mcp

Official

COA Plan

coa_plan

Generate a deployment plan by comparing your local project with a target environment and outputting a plan JSON file. Safe, non-destructive preview before applying changes.

Instructions

Generate a deployment plan. Reads the local project, diffs against the target environment, and writes a plan JSON (default coa-plan.json in the project root).

Non-destructive: produces a plan file only. Safe to call without confirmation. The plan is then applied via coa_deploy.

Requires COA cloud credentials (~/.coa/config or profile/token) and an environmentID.

V2 NOTICE: when the project contains V2 artifacts, a V2_DETECTED preflight warning attaches to the result (same shape as coa_create / coa_run). Execution is not blocked; see coalesce://context/sql-node-v2-policy for the two remaining rough edges.

Args:

  • projectPath (string, required)

  • environmentID (string, required)

  • out (string, optional): plan output path

  • gitsha, enableCache (optional)

  • profile, token (optional)

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outNoOutput path for the plan JSON. Relative paths resolve against the project root. Defaults to coa-plan.json in the project root.
tokenNoCoalesce refresh token override. Prefer ~/.coa/config over passing tokens through tool input.
gitshaNoOptional git SHA to embed in the plan manifest.
profileNoProfile name in ~/.coa/config. Falls back to the COALESCE_PROFILE env var, then to COA's own default (`[default]`).
workspaceNoCOA workspace name from workspaces.yml. Defaults to 'dev'.
enableCacheNoEnable coa's plan cache. Coalesce recommends leaving this off unless plan generation is slow.
projectPathYesAbsolute or relative path to the COA project root (the directory containing data.yml).
environmentIDYesTarget environment ID for the deployment plan.

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?

Annotations indicate non-destructive and non-read-only. Description reinforces non-destructive nature and adds context: reads local project, diffs, writes plan file, attaches preflight warnings if V2 artifacts detected, and is safe to call without confirmation. No contradictions 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?

Description is well-structured: front-loaded with main purpose and safety, then prerequisites, special notes, and arg list. The arg list is somewhat redundant with schema but not overly verbose. It earns its space with essential 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 complexity (8 params, output schema exists), the description covers all necessary aspects: purpose, behavior, safety, prerequisites, special V2 notice, argument summary, and return shape. Agent has sufficient information for correct 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?

Schema coverage is 100% with detailed descriptions. The description's 'Args' section adds some context beyond the schema, such as default output path and fallback behavior for profile/token. While schema provides complete semantic coverage, the description offers slight additional value.

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 generates a deployment plan by reading the local project, diffs against target, and writes a plan JSON. It uses specific verb 'generate' and resource 'deployment plan', and distinguishes from sibling coa_deploy which applies the plan.

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 the tool is non-destructive, safe to call without confirmation, and that the plan is applied via coa_deploy, providing clear when-to-use guidance. It also lists prerequisites (credentials, environmentID) and notes the V2_DETECTED preflight warning behavior.

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