hang_on_rod

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

With no annotations, the description carries the full behavioral burden and meets it: it explains the mechanism (adds a band, sews it, freezes it flat like a pin line, lays a rod along it), the visual outcome (looks like a rod pocket from the other side with rod ends showing), and hints at destructibility by advising a checkpoint first. No safety annotations exist to contradict this.

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 prose is front-loaded with the core purpose, then moves to a concise mechanism sentence and a bulleted Args block. Every sentence carries information—constraint, visual result, checkpoint warning, and each parameter—so the length is justified by the tool's complexity.

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?

For a 7-parameter tool with no output schema and no annotations, the description supplies everything needed: all parameters with units and constraints, the alternative tool, the visual behavior, the multi-panel requirement, and a checkpoint warning. Nothing required to invoke it correctly is missing.

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 description coverage is 0%, so the description must explain every parameter, and it does: pattern_index is defined as a panel or list of panels sharing one rod with equal top-edge heights, band_height has a unit and minimum constraint (rod_diameter + 10), rod_side maps 'front' to +z and 'back' to -z, and defaults are stated for fabric_index. This is strong compensation for an empty 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: 'Hang panels on a rod from a frozen header band,' and explicitly separates itself from make_rod_pocket by noting that the folded pocket approach is unreliable with several panels. It names the sibling and the scope, so an agent can tell the tools apart.

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?

It states the intended use ('the reliable way to hang curtains, noren and banners'), names the alternative and the condition where it is inferior ('make_rod_pocket's folded pocket is not reliable with several panels'), and gives an operational warning ('Save a checkpoint first'). This gives clear when/why guidance.

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