rhino_create_box

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write operation. The description adds minimal behavioral context: it mentions 'origin' but does not specify how the box is oriented (e.g., whether the origin is the base corner extending in positive X/Y/Z, or centered). It also does not disclose behavior about layer handling (e.g., if layer is null, uses current layer). Since annotations cover the safety profile, the description should add orientation and placement semantics, but it does not.

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 a single, efficient sentence with zero filler. Key parameters are listed up front, and the word 'cuboid' clarifies the shape. It is perfectly sized for the information it conveys.

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 simple create_* tool, the description is adequate but incomplete. There is no mention of the return value (output schema exists but is not explained), nor details about how coordinates relate to the Rhino document (e.g., world vs. construction plane). The absence of orientation and layer behavior leaves gaps. However, given the tool's simplicity and the presence of annotations, it is not severely under-specified. Ranked 3 for being minimally viable with clear 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 schema description coverage is 0% for the top-level params object, so the description must compensate. It lists origin, width, depth, and height but adds no new meaning beyond the schema's own property names (e.g., 'Width (X)'). It does not clarify units, orientation axes, or that origin is a corner point (which the schema does partially). Optional fields like name and layer are omitted from the description, leaving their role unclear. The description fails to enrich the parameter semantics.

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 clearly states the verb 'Create' and the resource 'box/cuboid', then lists the key parameters (origin, width, depth, height). This is specific enough to distinguish from siblings like rhino_create_sphere or rhino_create_cylinder, even though many create_* tools share the same verb. The naming convention and parameter list make the purpose unambiguous.

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 implies usage: if you need a box, use this tool. However, it does not explicitly state when to prefer this over alternatives, nor does it mention exclusions (e.g., 'for rectangular prisms with axis-aligned edges use this, otherwise use rhino_create_extrusion'). Context from sibling names (e.g., rhino_create_cylinder) suggests the distinction, but no explicit guidance is provided. This is adequate but not proactive.

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