tdmcp

Create fluid sim

create_fluid_sim

Create a real-time 2D fluid simulation in TouchDesigner with controllable dye, viscosity, and audio-reactive injection, outputting node paths and a preview image.

Instructions

Build a real-time 2D fluid/ink/dye simulation (stable-fluids style: semi-Lagrangian advection + Jacobi pressure solve + gradient-subtract projection + dye advection) as a stack of GLSL TOPs in feedback loops inside a new baseCOMP under parent_path. Exposes artist-facing controls (dye color, injection radius/strength, viscosity, dissipation, pressure iterations, inject U/V) and optionally binds a CHOP at audio_path so audio drives the dye injection strength. With injection_mode='auto', a slow LFO drives the splat point so the sim shows life with no input. Returns a summary plus a JSON block with the container path, created node paths, the dye_out output path, exposed controls, any 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_fluid_sim"
  }
}

Input Schema

Name	Required	Description	Default
`dye_color`	No	Injected dye color as a '#rrggbb' hex string.	#ff3a8c
`viscosity`	No	Velocity dissipation per frame (0–1). Higher = thicker fluid.
`audio_path`	No	Optional CHOP path; channel 0 multiplies injection strength when set.
`resolution`	No	Sim grid resolution (square). 512 is safe on integrated GPUs.	512
`dissipation`	No	Dye decay per frame (0.9–1.0). <1 fades trails.
`parent_path`	No	Parent network where the fluid_sim container is created.	/project1
`injection_mode`	No	How the splat point/strength is driven.	auto
`expose_controls`	No	Auto-expose an artist-facing control panel on the container.
`injection_radius`	No	Radius of the dye/force splat in UV units (0.01–0.5).
`injection_strength`	No	Multiplier on dye + velocity splat per frame (0–2).
`pressure_iterations`	No	Jacobi iterations per frame (1–60). Higher = more incompressible.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.13.1Aug 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses that it creates a new baseCOMP, builds a stack of GLSL TOPs, exposes controls, optionally binds a CHOP, and returns a JSON summary with errors and preview. It also notes resolution safety ('512 is safe on integrated GPUs'), adding behavioral context.

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 a single dense paragraph, but every sentence adds value. It front-loads the core purpose and algorithm, then lists features and return value. It is longer than average but proportionate to the tool's complexity, with no filler.

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 11 parameters, no output schema, and the complexity of creating a networked simulation, the description is complete. It explains what is built, how it is built (algorithm, TOPs, feedback loops), how controls and audio binding work, and what the return value includes (paths, errors, warnings, preview). The absence of output schema is compensated by describing the JSON block contents.

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%, so parameters are well-documented. The description adds meaning by grouping parameters into artist-facing controls and mentioning behavior like 'injection_mode='auto'', where an LFO drives the splat point, and the audio_path channel multiplier. This enriches understanding beyond the raw schema.

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's purpose with a specific verb ('Build') and resource ('real-time 2D fluid/ink/dye simulation... as a stack of GLSL TOPs in feedback loops inside a new baseCOMP under parent_path'). It differentiates from siblings like create_particle_system or create_reaction_diffusion by naming the stable-fluids algorithm and specific output structure.

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?

The description gives strong context for when to use it: when a real-time 2D fluid simulation is needed, including artist-facing controls, optional audio reactivity, and auto mode for no input. It does not explicitly name alternative tools or exclusions, but the use case is clearly scoped so an agent can infer appropriate usage.

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

Deploy Server