Skip to main content
Glama
Coalesce-Software-Inc

coalesce-transform-mcp

Official

Create Workspace Node from Predecessor

create_workspace_node_from_predecessor

Creates a workspace node from predecessor nodes, auto-populates columns, and applies optional column transforms, WHERE filters, or aggregation in a single call.

Instructions

Create a workspace node from one or more predecessor nodes, fetch it, and verify that columns were auto-populated from those predecessors before applying any optional changes.

SINGLE-CALL WORKFLOW: You can create a node AND apply column transforms, WHERE filters, or aggregation in one call:

  • columns + whereCondition: Replace auto-populated columns with specific transforms and add a WHERE filter — no separate replace_workspace_node_columns needed

  • groupByColumns + aggregates: Convert to an aggregation node with GROUP BY — no separate convert_join_to_aggregation needed These are mutually exclusive: use columns OR groupByColumns+aggregates, not both.

REQUIRED: Before calling this tool, call plan_pipeline with goal, sourceNodeIDs, and repoPath to discover and rank available node types. Use the nodeType from the plan result — do NOT guess or hardcode node types like 'Stage', 'View', or numeric IDs like '65'. The planner scans all committed node type definitions and scores them against your use case.

SPECIALIZED TYPES WARNING: Do NOT use Dynamic Tables, Incremental Load, Materialized View, or other specialized types unless the user explicitly requests that pattern (e.g., 'near-real-time refresh', 'continuous refresh', 'incremental processing'). For standard batch ETL, CTE decomposition, and general transforms, use Stage or Work. The response includes nodeTypeValidation.warning if a specialized pattern was detected without matching context — always check this field.

JOIN INTELLIGENCE: For multi-predecessor nodes (joins), this tool automatically:

  • Analyzes common columns between each predecessor pair

  • Returns joinSuggestions with normalized column names and their left/right counterparts

  • Reports which predecessors are represented in the resulting column references

  • Warns if any predecessor is missing from the auto-populated columns

AUTOMATIC CONFIG: When repoPath is provided, this tool automatically runs intelligent config completion after creation — reading the node type definition, setting node-level config defaults, and applying column-level attributes (isBusinessKey, isChangeTracking, etc.). The configCompletion result shows what was applied.

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

For guidance on node types, storage locations, and SQL patterns, see resources: coalesce://context/data-engineering-principles, coalesce://context/storage-mappings, coalesce://context/sql-platform-selection

Args:

  • workspaceID (string, required): The workspace ID

  • nodeType (string, required): Node type from plan_pipeline

  • predecessorNodeIDs (string[], required): One or more predecessor node IDs

  • changes (object, optional): Partial fields to apply after creation

  • columns (array, optional): Replace auto-populated columns (mutually exclusive with groupByColumns)

  • whereCondition (string, optional): WHERE filter (only with columns)

  • groupByColumns (string[], optional): GROUP BY columns (with aggregates)

  • aggregates (array, optional): Aggregate columns (with groupByColumns)

  • joinType (string, optional): JOIN type for multi-predecessor aggregation

  • repoPath (string, optional): Local repo path for config completion

  • goal (string, optional): Intent for node type validation

Returns: { nodeID, created, joinSuggestions?, nodeTypeValidation?, configCompletion? }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNoThe goal or intent for this node (e.g., 'deduplicate customer records', 'join orders with customers'). Used to validate that the chosen nodeType is appropriate for the task. Same value you would pass to plan_pipeline.
changesNoOptional partial fields to apply after successful auto-population validation, such as name, description, config, metadata, database, schema, or locationName.
columnsNoReplace auto-populated columns with these specific columns and transforms. Mutually exclusive with groupByColumns/aggregates.
joinTypeNoJOIN type for multi-predecessor aggregation nodes. Defaults to INNER JOIN.
nodeTypeYesThe type of node to create. IMPORTANT: Call plan_pipeline first to discover and rank available node types — use the nodeType from its result. Format: 'PackageName:::ID' for package types (e.g., 'base-nodes:::Stage') or simple name ('Stage') for built-in types. Always prefer the package-prefixed format returned by plan_pipeline.
repoPathNoPath to local Coalesce repository for automatic config completion after creation.
aggregatesNoAggregate columns. Must be provided with groupByColumns. Mutually exclusive with columns.
workspaceIDYesThe workspace ID
groupByColumnsNoGROUP BY columns for aggregation. Must be provided with aggregates. Mutually exclusive with columns.
whereConditionNoWHERE filter to append to the joinCondition (without the WHERE keyword). Only valid with columns, not with groupByColumns/aggregates.
predecessorNodeIDsYesOne or more predecessor node IDs to link to the new node

Output Schema

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

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

Discloses automatic config completion, join intelligence with joinSuggestions, and nodeTypeValidation warnings. Annotations (readOnlyHint=false, etc.) are consistent; description adds context about mutability and side effects beyond 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?

Well-structured with headings and front-loaded purpose, but lengthy. Every sentence adds value given tool complexity. Could be slightly more concise, but appropriate for the feature-rich tool.

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?

Covers entire workflow: prerequisite planning, single-call options, specialized types warning, join intelligence, automatic config, and references external resources. Output schema exists, so return values are handled separately. Highly complete.

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 critical meaning: mutual exclusivity of columns vs groupByColumns+aggregates, required nodeType from plan_pipeline, goal for validation, and detailed explanations for changes, whereCondition, and other 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?

States explicit verb+resource: 'Create a workspace node from one or more predecessor nodes'. Distinguishes from siblings like create_workspace_node_from_scratch by emphasizing predecessor-based creation and auto-population verification.

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?

Provides explicit when-to-use: single-call workflow for combined creation/transforms, warnings against guessing node types, requirement to call plan_pipeline first, and exclusion of overrideSQL. Clearly differentiates from replace_workspace_node_columns and convert_join_to_aggregation.

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