orient_object

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

With no annotations, the description carries the full burden and largely meets it: it discloses the optimization objectives (support area, bed area, height), the overhang threshold semantics, that three candidates plus current values are returned, and that apply=False is a dry run. It stops short of stating irreversibility, undo behavior, or what 'apply' does to the object's existing transform beyond implication.

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 optimization criteria, return behavior, and parameter semantics are packed into three compact sentences with no filler. The scoring logic is front-loaded before the parameter-specific details.

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 mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers return values, optimization criteria, and the dry-run mode. Remaining gaps are the required object identifier and prerequisites, but nothing critical to invoking 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 coverage is 0%, and the description meaningfully compensates for three of four parameters: overhang_angle is defined via faces leaning more than that many degrees from vertical, choice is explained as selecting candidate 2 or 3, and apply is explained as compare-only when false. The required 'object' parameter's identifier format is never described.

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 and resource ('Turn an object the way up it prints best') and anchors it to a known behavior ('like Bambu Studio's Auto orientation'). This clearly distinguishes it from siblings like lay_flat, arrange, and transform_object, which either flatten, pack, or apply explicit transforms.

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 usage context: apply=False only compares, choice=2/3 selects another candidate, and 'Look at preview_plate afterwards' supplies an explicit follow-up step. It lacks explicit routing away from alternatives such as lay_flat, but the intended workflow is clear.

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