Create Engine COMP

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

The description discloses several non-obvious behaviors beyond annotations: sub-process spin-up forks a TD process, first cook may take multiple seconds on slow disks and is not a hang, and par names (reload/usecolormap/performmode) are guarded with hasattr so unverified names degrade to warnings. This is rich contextual information that annotations (readOnlyHint, openWorldHint, destructiveHint) do not provide.

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 dense and structured, front-loading the core purpose before adding usage context, a note about output connectors, a sibling comparison, and a performance warning. It is somewhat longer than strictly necessary, but every sentence contributes meaningful information. The 'Note:' at the end is a valuable caveat that prevents false hang detection.

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 the tool's complexity (external subprocess, Engine COMP behavior, guarded parameters) and the absence of an output schema, the description is remarkably complete. It explains side effects (separate TD process, crash domain), output behavior (outTOP/outCHOP/outSOP/outDAT connectors), a critical performance characteristic (first-cook latency), parameter safety, and its relationship to make_portable_tox. There are no major gaps.

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?

The input schema provides 100% description coverage for all six parameters, including defaults and enum details. The description adds some context about how parameters map to Engine COMP behavior (e.g., reload pulse, perform-mode override, color-map toggle) and notes the output connectors that result from tox_path, but these are largely redundant with existing schema descriptions. No additional syntax or format guidance beyond the 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 opens with a specific verb and resource: 'Drop a TouchDesigner Engine COMP that loads an external .tox in a separate TD subprocess.' It clearly defines the tool's scope (independent crash domain) and distinguishes it from siblings like make_portable_tox by focusing on runtime isolation and hosting heavy/unstable graphs.

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 states when to use the tool: 'ideal for hosting heavy or unstable subgraphs.' It also names a complementary sibling (make_portable_tox), which helps orient the agent. However, it does not explicitly state when not to use it or name direct alternatives (e.g., simple COMP creation), so it stops short of full usage exclusion guidance.

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