Create fluid sim

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.

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.

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.

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.

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.

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.