Skip to main content
Glama
Coalesce-Software-Inc

coalesce-transform-mcp

Official

Replace Workspace Node Columns

replace_workspace_node_columns
Idempotent

Replace all columns in a workspace node with a new set of columns, optionally applying a WHERE filter and additional changes.

Instructions

Replace all columns in a workspace node with a new set of columns, optionally applying a WHERE filter and additional changes in a single call.

Do not use overrideSQL or override.* fields; SQL override is disallowed in this project.

Use this when:

  • Applying column transforms (UPPER, LEFT, COALESCE, etc.) after node creation

  • Adding WHERE filters at the same time as column transforms

  • Converting from a simple join to GROUP BY aggregation

  • Completely replacing column definitions with aggregate functions

Prefer this over separate update_workspace_node calls. Combine column replacement + WHERE filter in one call.

Example: Apply transforms and filter in one call: { columns: [ { name: 'CUSTOMER_ID', transform: '"CUSTOMER_LOYALTY"."CUSTOMER_ID"' }, { name: 'CITY', transform: 'UPPER("CUSTOMER_LOYALTY"."CITY")' }, { name: 'CONTACT_INFO', transform: 'COALESCE("CUSTOMER_LOYALTY"."E_MAIL", "CUSTOMER_LOYALTY"."PHONE_NUMBER")' } ], whereCondition: '"CUSTOMER_LOYALTY"."CUSTOMER_ID" IS NOT NULL AND ("CUSTOMER_LOYALTY"."E_MAIL" IS NOT NULL OR "CUSTOMER_LOYALTY"."PHONE_NUMBER" IS NOT NULL)' }

IMPORTANT: Use whereCondition for WHERE filters — do NOT construct {{ ref() }} syntax yourself. The FROM clause is already set up from node creation. The whereCondition is appended to the existing joinCondition automatically.

Args:

  • workspaceID (string, required): The workspace ID

  • nodeID (string, required): The node ID

  • columns (array, required): Complete new columns array

  • whereCondition (string, optional): WHERE filter to append

  • additionalChanges (object, optional): Additional fields to update

Returns: { nodeID, warning?, validation? }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeIDYesThe node ID
columnsYesComplete new columns array to replace metadata.columns. Each column should include name and may include transform, dataType, description, nullable, sources, and other hydrated metadata fields.
workspaceIDYesThe workspace ID
whereConditionNoOptional WHERE filter to append to the node's existing joinCondition. Just provide the condition — do NOT include the WHERE keyword or construct {{ ref() }} syntax. The FROM clause is already set from node creation. Example: '"LOCATION"."LOCATION_ID" IS NOT NULL AND "LOCATION"."LOCATION_ID" != 0'
additionalChangesNoOptional additional fields to update, such as name, description, config, or metadata. Object fields are deep-merged; arrays are replaced. Do NOT include metadata.sourceMapping or customSQL — use whereCondition for WHERE filters, apply_join_condition for join setup, or convert_join_to_aggregation for GROUP BY patterns.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeIDNo
createdNo
warningNo
nextStepsNo
validationNo
joinSuggestionsNo
configCompletionNo
nodeTypeValidationNo
configCompletionSkippedNo
Behavior4/5

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds that SQL override is disallowed, whereCondition is appended to existing joinCondition, and FROM clause is pre-set. This provides useful context beyond annotations, though auth/rate limits are not mentioned but not expected.

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 with clear sections (purpose, disallowed, when to use, example, args, returns). It is relatively long but every sentence adds value. Front-loaded with the main action. Minor redundancy (e.g., 'Args' section repeats schema) but acceptable.

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 (5 parameters with nested objects, output schema), the description covers all aspects: what the tool does, how to use each parameter, constraints (no overrideSQL, no ref()), behavior (append whereCondition), and return format. No gaps identified.

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 description adds significant meaning: 'columns' is explicitly described as a complete replacement array with required name and optional transform/dataType etc. 'whereCondition' clarifies it appends to joinCondition, with an example avoiding ref syntax. 'additionalChanges' explains deep-merge behavior and lists excluded fields. This far exceeds 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 the tool replaces all columns in a workspace node with a new set, optionally adding a WHERE filter. It distinguishes from siblings like update_workspace_node by emphasizing a single-call column replacement with filter. The verb 'Replace' and resource 'workspace node columns' are specific and unambiguous.

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 lists when to use: applying column transforms, adding WHERE filters, converting to GROUP BY, replacing with aggregate functions. Also states what to avoid (overrideSQL, override.*) and advises preferring this over separate update_workspace_node calls. Includes a concrete example.

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