tdmcp

Create terrain

create_terrain

Build a procedural heightmap landscape with animated noise displacement and elevation shading, adding optional water and fog fade for a complete terrain scene.

Instructions

Build a procedural heightmap landscape: an animated Noise TOP height field displaces a subdivided Grid SOP along Z in a GLSL vertex-displacement MAT (real 2.5D geometry, elevation-shaded from a low→high colour ramp), lit by a key Light, framed by a raised angled Camera, and rendered. Optionally adds a flat translucent water plane at water_level and a camera-distance fog fade into the sky/background colour. Distinct from create_visual_system's 'terrain' keyword (which only maps to a noise_landscape recipe) — this is a dedicated, fully parameterized terrain pipeline with its own displacement material, water, and fog. Creates a new baseCOMP under parent_path. Exposes Height, Drift, WaterLevel, and Zoom controls. Returns a summary plus a JSON block with the container path, created node paths, output path, exposed controls, node errors, warnings, and an inline preview image.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_terrain"
  }
}

Input Schema

Name	Required	Description	Default
`fog`	No	Fade the far terrain into `background` by camera distance (volumetric-ish haze).
`drift`	No	Scroll speed of the noise height field along Z per second so the landscape slowly evolves. 0 = static terrain. Reads 0 when the TD timeline is paused.
`water`	No	Add a flat translucent water plane at `water_level` cutting through the terrain.
`height`	No	Displacement amount along Z: how far bright pixels push the surface up. 0 = flat.
`low_color`	No	Colour of the valleys / lowest elevation (RGB 0..1).
`background`	No	Sky / background + fog colour (RGB 0..1).
`high_color`	No	Colour of the peaks / highest elevation (RGB 0..1).
`parent_path`	No	Parent network where the terrain container is created (default '/project1').	/project1
`water_color`	No	Water plane colour (RGB 0..1). Rendered semi-transparent.
`water_level`	No	Z elevation of the water plane, in the same units as `height`.
`noise_period`	No	Noise TOP period — larger = broader, smoother hills; smaller = tighter, rockier.
`subdivisions`	No	Grid resolution (rows = cols). Higher = finer relief and smoother displacement, but more vertices to push. 160 gives a 160×160 plane.
`expose_controls`	No	When true (default), expose live Height / Drift / WaterLevel / Zoom controls.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.13.1Aug 2, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only signal readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description carries the behavioral burden and delivers—stating it 'Creates a new baseCOMP under parent_path,' exposes Height/Drift/WaterLevel/Zoom controls, and details the JSON return payload (container path, node paths, output path, errors, warnings, inline preview). No contradiction with annotations exists.

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 longer than average (about eight sentences) but front-loads the core purpose and every clause adds information: pipeline components, optional water/fog, sibling distinction, creation path, exposed controls, and return format. It is on the verbose side but contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter creation tool with no output schema, the description covers the full build pipeline, optional behaviors (water, fog), create location, live controls, and exactly what the return payload contains. Prerequisites and failure modes are not spelled out, but node errors/warnings are part of the declared return, keeping this sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema-description coverage, the schema already documents all 13 parameters, so the baseline is 3. The description adds only marginal value—mapping exposed controls (Height, Drift, WaterLevel, Zoom) to the UI—and references water_level in context, but does not clarify anything the schema descriptions leave ambiguous.

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 opens with a specific action—'Build a procedural heightmap landscape'—and enumerates the exact pipeline (Noise TOP, Grid SOP, GLSL vertex-displacement MAT, light, camera, render). It explicitly differentiates itself from create_visual_system's 'terrain' keyword, which is the closest sibling. The verb+resource+technical scope fully anchors the tool's purpose.

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 explicitly names the main alternative: 'Distinct from create_visual_system's "terrain" keyword… this is a dedicated, fully parameterized terrain pipeline with its own displacement material, water, and fog.' This communicates when the more complete pipeline is needed versus the simpler recipe mapping. It does not enumerate every terrain-adjacent sibling, but the primary confusion point is directly addressed with a clear when-not distinction.

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

Deploy Server