Render NiimBlue label

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

Annotations only declare the safety profile (readOnly=false, idempotent, non-destructive); the description adds substantial context beyond that: the returned artifact is a 1-bit PNG thresholded at 140, per-object rendered boxes, warnings with fixes, and a #load= link. It also discloses a side effect the annotations miss — the link replaces the user's currently open label after a confirm — and that save_as writes two files into the templates folder. This is exactly what annotations cannot convey.

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?

Effectively sized for a 15-parameter rendering tool with many hard constraints, and it front-loads purpose and returns before the rule list. It reads as a dense wall of text rather than grouped bullets, and the dpi floors duplicate enum/schema notes, so it is slightly more repetitive than needed.

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 printer-model enum, nested object union, and an existing output schema, the description still covers the pieces an agent needs to succeed: units and dpi, interpolation and row/CSV semantics, template and save_as lifecycle, and the iterate-until-warning-free loop. Nothing material is left for the agent to guess.

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 and the schema already documents all 15 parameters thoroughly. The description still adds meaning beyond it: dpi-to-dot conversion (8/mm at 203 dpi, 11.81 at 300), top-left origin, paint order as array order, NiimBlue/fabric property naming, and the {key}/rows interpolation contract. That said, it partly repeats schema-stated floors (e.g. font ≥16 px).

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?

States a specific verb+resource ('Design a NIIMBOT label for NiimBlue') and immediately scopes the output ('see exactly what the printhead burns'). The render step is clearly distinguished from the sibling list_templates/get_template tools, which only manage saved args. An agent can tell what this does without opening the schema.

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?

Gives concrete operational flow: fix every warning then re-render, and 'final call: include_json' for the .json export, plus the ordering caution that the link replaces the label currently open in NiimBlue and the user must save first. It does not explicitly say when to prefer this tool over list_templates/get_template, but the workflow guidance is otherwise clear.

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