Create pose ControlNet driver

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

With annotations already declaring it is not read-only and not destructive, the description adds valuable detail: GPU-rasterized via a single GLSL TOP, sampling via CHOP-to-TOP, optional auto-wiring to external senders, and the explicit clarification that no model inference occurs. It fully supplements the annotation without contradiction.

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 three sentences and every sentence adds information: rendering output, internal mechanism, and optional output wiring. It is well-structured and front-loaded, though slightly longer than strictly necessary since some details (e.g., per-limb RGB lines, joint discs) are already evident from the title and parameters.

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 (15 parameters, no output schema), the description is adequate: it explains what is produced (a TOP), how it receives data (pose CHOP), and its role in a ControlNet pipeline. It does not describe return values, but for a node-creating tool this is not a gap. The lack of an output schema is mitigated by the clear statement of the render output.

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 the baseline is 3 per the rubric. The description does not significantly add parameter-level meaning beyond the schema; it mentions the default 512×512 and the source from an existing pose CHOP, but these are already captured in the property descriptions. No additional compensation needed.

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 uses a specific verb 'Render' and clearly identifies the resource (canonical OpenPose-colored stick figure TOP) and purpose (driver conditioning image for ControlNet). It distinguishes itself from sibling tools like create_pose_tracking by stating it consumes the pose CHOP and explicitly says 'No model inference'.

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 places the tool in a pipeline: it takes a pose CHOP 'produced by create_pose_tracking' and feeds into 'a downstream Stable Diffusion / ComfyUI / StreamDiffusion ControlNet node'. This implies when to use it, though it does not explicitly name alternatives or when-not to use it, so it falls short of a 5.

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