tdmcp

Create POP field (GPU points)

create_pop_field

Build a GPU point field in TouchDesigner: choose noise, grid, or sphere layout, animate spin, set point size, and get a null TOP render output with adjustable controls.

Instructions

Build a GPU point field using TouchDesigner's POP (Point OPerator) family — a generator POP (chosen by pattern: 'noise' scatters count points and displaces them with a Noise POP for a moving cloud, 'grid' a flat lattice, 'sphere' a shell), a Transform POP that spins the whole field over time, then a render path (POP to SOP → Geometry COMP → Render TOP) output as a Null TOP. Creates a new baseCOMP under parent_path holding all of these and exposes PointSize and Spin knobs. NOTE: POPs are flagged Experimental in this TD build and the POP render path is uncertain, so this tool is built fail-forward and probe-first — the POP chain and render wiring are best-effort (failures become warnings) while the output Null is always created, and the result's extra.unverified lists every POP op type and the render path attempted so you can live-validate. Returns a summary plus a JSON block with the container path, created node paths, generator/transform/render/output paths, exposed controls, node errors, warnings, the unverified probe record, 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_pop_field"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	Name for the self-contained POP-field container created under parent_path.	pop_field
`spin`	No	Degrees/sec rotation of the whole field around Y (a Transform POP animates it over time), exposed as the live Spin knob.
`count`	No	Approximate point count. Used directly for the 'noise' pattern; 'grid'/'sphere' approximate it via a rows×cols layout near this total.
`pattern`	No	Point layout/source. 'noise' (default) = a Point Generator POP scatters `count` points which a Noise POP displaces into a moving cloud. 'grid' = a flat Grid POP lattice. 'sphere' = points on a Sphere POP shell.	noise
`point_size`	No	Rendered point size (Render TOP point size), exposed as the live PointSize knob.
`resolution`	No	Render resolution [width, height] of the Render TOP and the output Null TOP.
`parent_path`	No	Parent COMP path the POP-field container is created inside (default '/project1').	/project1

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.13.1Aug 2, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes beyond annotations by disclosing that POPs are Experimental, the render path is uncertain, the tool fails forward (failures become warnings), the output Null is always created, extra.unverified tracks POP types and render path, and returns detailed error/warning info. 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 long but front-loaded with the main purpose and includes essential caveats and return info. Every sentence adds value, though the density may be high; no wasted words.

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 no output schema, the description explicitly lists return contents including paths, controls, errors, warnings, unverified probe record, and preview image. It also covers creation behavior, experimental risks, and parameter effects, making it fully sufficient for invoking the tool.

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?

Schema covers all 7 parameters with detailed descriptions (100% coverage). The description reinforces parameter meanings (e.g., pattern values) but adds no new semantic info beyond the schema, so baseline 3 applies.

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 'Build a GPU point field using TouchDesigner's POP family' and details the generator, transform, render path, and Null TOP output, clearly distinguishing it from sibling tools like create_gpu_particle_field or create_pop_geometry.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides rich context about what the tool does (patterns, transform, render path, knobs) but does not explicitly state when to prefer it over alternatives or when not to use it. The experimental POP note implies caution but is not an explicit usage guideline.

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

Deploy Server