rhino_rectangle

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

Annotations already carry the write-safety signal (readOnlyHint=false), so the bar is lower. The description adds genuine behavior beyond that: the result is disclosed as 'a closed polyline' rather than a native rectangle curve or surface, and the XY-plane claim implies that corner z is ignored. It does not mention side effects like auto-creating missing layers, but those are documented in the schema.

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?

A single sentence with zero filler; the verb is front-loaded and the two qualifiers ('closed polyline', 'XY plane') are the highest-value facts an agent needs. Every word earns its place, and no information is buried or repeated.

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 tool with a nested 6-field input, an output schema, and over 100 siblings, one sentence is lean but workable because the schema and annotations carry much of the load. The real gaps are the ambiguity about whether a non-zero z on the corner is honored or ignored, and the absence of any routing guidance versus rhino_cmd_rectangle. These are clear, fixable omissions rather than fatal ones.

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 description names no parameters, so it adds zero meaning beyond the input schema; with schema description coverage at 0%, it does not compensate as required. The only indirect signal is 'on the XY plane,' which hints that the corner's z value is irrelevant. The nested schema's own per-field descriptions (e.g., 'Lower-left corner (in plane)', 'Width along plane X') mitigate real-world harm, but they come from the schema, not the tool description.

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 ('Add'), a specific resource ('a rectangle'), and two decision-critical qualifiers: the result is 'a closed polyline' and it is placed 'on the XY plane.' This distinguishes it from rhino_box (3D) and surface-creation tools. However, it does not explicitly differentiate from the near-twin sibling rhino_cmd_rectangle, so it falls short of full sibling distinction.

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?

No when-to-use guidance is given; the description never mentions alternatives, exclusions, or selection criteria. Among the siblings, rhino_cmd_rectangle appears to be the command-driven counterpart, but an agent is given no basis for choosing between them. The XY-plane qualifier only weakly implies 2D use and does not count as real routing guidance.

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