Kiln

Overview Schema Source Related Servers Discussions Admin

rotate_model

Rotate STL or 3MF models by specified X, Y, or Z angles before slicing to improve print quality and reduce wobble artifacts.

Instructions

Rotate a 3D model file (STL or 3MF) by specified angles before slicing.

Useful for improving print quality — rotating a tall narrow part 45° around
the Z axis can reduce toolhead-induced wobble and ringing artifacts.

Args:
    input_path: Path to the STL or 3MF file to rotate.
    rotation_z: Rotation around Z axis in degrees (most common — rotates
        on the build plate).
    rotation_x: Rotation around X axis in degrees.
    rotation_y: Rotation around Y axis in degrees.
    output_path: Where to save the rotated file.  Defaults to
        ``<input>_rotated.<ext>``.

Returns dict with ``output_path`` (path to rotated file) and
``rotations_applied``.

Pair with ``reslice_with_overrides`` to re-slice the rotated model with
adjusted settings (e.g., stronger brim after rotation).

INLINE 3D STAGE: on success this tool opens Kiln's interactive 3D stage — an inline viewer panel the user can orbit, zoom, and turn over — in hosts that render MCP Apps panels (Kiln's hosted connection attaches a browser stage link for hosts that don't). Oversized meshes are decimated automatically for the stage; the PNG preview is the floor, not the whole experience.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input_path": "<input_path>"
    },
    "name": "rotate_model"
  }
}

Input Schema

Name	Required	Description
`input_path`	Yes	Path to the STL or 3MF file to rotate.
`rotation_x`	No	Rotation around X axis in degrees. Default: 0.0.
`rotation_y`	No	Rotation around Y axis in degrees. Default: 0.0.
`rotation_z`	No	Rotation around Z axis in degrees (most common — rotates on the build plate). Default: 0.0.
`output_path`	No	Where to save the rotated file. Defaults to ``<input>_rotated.<ext>``.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.5.1Nov 5, 2026

addedInput schema / properties / input_path / description

Added value: +"Path to the STL or 3MF file to rotate."

addedInput schema / properties / output_path / description

Added value: +"Where to save the rotated file.  Defaults to ``<input>_rotated.<ext>``."

changedInput schema / properties / rotation_x / description

Previous value: -"Default: 0.0."New value: +"Rotation around X axis in degrees. Default: 0.0."

changedInput schema / properties / rotation_y / description

Previous value: -"Default: 0.0."New value: +"Rotation around Y axis in degrees. Default: 0.0."

changedInput schema / properties / rotation_z / description

Previous value: -"Default: 0.0."New value: +"Rotation around Z axis in degrees (most common — rotates on the build plate). Default: 0.0."

Changed7 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / output_path / default
```
Removed value: -null
```
- removedInput schema / properties / rotation_x / default
```
Removed value: -0
```
- addedInput schema / properties / rotation_x / description
```
Added value: +"Default: 0.0."
```
- removedInput schema / properties / rotation_y / default
```
Removed value: -0
```
- addedInput schema / properties / rotation_y / description
```
Added value: +"Default: 0.0."
```
- removedInput schema / properties / rotation_z / default
```
Removed value: -0
```
- addedInput schema / properties / rotation_z / description
```
Added value: +"Default: 0.0."
```

Changed1 schema field changedv1.3.0Jul 30, 2026

changedOutput schema / (root)

Previous value: -{
-  "additionalProperties": true,
-  "title": "rotate_modelDictOutput",
-  "type": "object"
-}New value: +null

First observedv0.1.0Jul 4, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds useful behavior: it writes a new file at output_path (default derived from input), reports rotations_applied, and opens an interactive 3D stage with automatic decimation of oversized meshes. That stage paragraph is genuine disclosure, but it is framed promotionally and omits whether the input file is left untouched and what the stage costs in latency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core sentence is front-loaded, but the Args section duplicates a fully documented schema word-for-word, and the closing paragraph about the inline 3D stage is long and partly marketing copy. Roughly a third of the text could be removed without losing agent-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by naming the returned keys (output_path, rotations_applied) and the post-rotation workflow. For a five-parameter mesh mutation it is nearly complete, missing only whether the source file is preserved and any constraints on combining the three Euler angles.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the Args block mostly restates the schema verbatim, including the 'most common — rotates on the build plate' note for rotation_z. No new semantics (axes convention, degree sign, effect of combining axes, output extension rules) are added beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource plus the supported formats and pipeline stage ('Rotate a 3D model file (STL or 3MF) ... before slicing'). It is clearly distinct in practice from mesh siblings like mirror_mesh_model or rescale_model, though it never explicitly contrasts itself with auto_orient_model, which also changes orientation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states why you would rotate (reduce toolhead-induced wobble on tall narrow parts) with a concrete example, and gives a follow-up routing hint ('Pair with reslice_with_overrides'). It stops short of naming when NOT to use it or pointing to the automatic-orientation alternative.

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

Deploy Server