rotate_model

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

With no annotations provided, the description carries the full disclosure burden — and it delivers. It reveals the 3D stage inline viewer side effect, automatic decimation of oversized meshes, the return dict structure (output_path, rotations_applied), and the output_path default naming convention. This goes well beyond minimal disclosure by flagging that the PNG preview is not the whole experience and that a browser stage link is used for hosts without MCP Apps panel support.

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 well-structured with clear sections: purpose, use case, Args, Returns, and pairing recommendation. It's front-loaded with the purpose statement. The 3D stage paragraph is slightly verbose — 'in hosts that render MCP Apps panels (Kiln's hosted connection attaches a browser stage link for hosts that don't)' could be tightened — but every sentence contributes meaningful information.

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 5-parameter tool with no annotations and no output schema, the description is remarkably complete: input formats, all parameter semantics, return dict, default behaviors, and side effects are covered. The only minor gap is that it doesn't explicitly confirm the original file is left unmodified (non-destructive), which is implied by 'save the rotated file' but not stated — an important detail for a mutation-adjacent tool with zero annotation safety hints.

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 fully compensate — and it does, documenting all 5 parameters. Each rotation axis gets units and context ('rotation_z: ... most common — rotates on the build plate'), input_path specifies valid file types (STL or 3MF), and output_path explains the default naming pattern `<input>_rotated.<ext>`. The description is the complete source of parameter truth.

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+resource: 'Rotate a 3D model file (STL or 3MF) by specified angles before slicing.' It clearly identifies what the tool does and distinguishes it from siblings like auto_orient_model, optimize_print_orientation, and rescale_model by emphasizing manual angle specification. The concrete use case (reducing toolhead-induced wobble by rotating 45° around Z) reinforces purpose.

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 provides clear context: 'Useful for improving print quality — rotating a tall narrow part 45° around the Z axis can reduce toolhead-induced wobble and ringing artifacts.' It explicitly names a companion tool to pair with ('Pair with reslice_with_overrides') and explains the scenario for using it. However, it doesn't explicitly state when NOT to use it versus alternatives like auto_orient_model, though the manual-angle specificity implicitly creates that boundary.

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