Kiln

Overview Schema Source Related Servers Discussions Admin

rescale_model

Destructive

Scale an STL model to match a printer's build volume or exact dimensions using uniform height, max-dimension, multiplier, or per-axis scaling.

Instructions

Rescale an STL model to meet dimensional targets.

        Useful when a generated model is the wrong size for the printer's
        build volume or doesn't match the desired dimensions.

        **Uniform scaling** -- provide exactly ONE of:

        - ``target_height_mm``: Scale so Z-axis equals this value.
        - ``scale_factor``: Uniform multiplier (2.0 = double size).
        - ``max_dimension_mm``: Scale down so largest axis fits this limit.

        **Per-axis scaling** -- provide ``scale_x``, ``scale_y``, and/or
        ``scale_z``.  Omitted axes default to 1.0 (no change).

        Cannot combine uniform and per-axis options.

        Args:
            file_path: Path to the STL file to rescale (modified in-place).
            target_height_mm: Desired Z-axis height in mm.
            scale_factor: Uniform scale multiplier.
            max_dimension_mm: Maximum dimension on any axis.
            scale_x: Per-axis X scale factor.
            scale_y: Per-axis Y scale factor.
            scale_z: Per-axis Z scale factor.

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": {
      "file_path": "<file_path>"
    },
    "name": "rescale_model"
  }
}

Input Schema

Name	Required	Description
`scale_x`	No	Per-axis X scale factor.
`scale_y`	No	Per-axis Y scale factor.
`scale_z`	No	Per-axis Z scale factor.
`file_path`	Yes	Path to the STL file to rescale (modified in-place).
`scale_factor`	No	Uniform scale multiplier.
`max_dimension_mm`	No	Maximum dimension on any axis.
`target_height_mm`	No	Desired Z-axis height in mm.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.5.1Nov 5, 2026
- addedInput schema / properties / file_path / description
```
Added value: +"Path to the STL file to rescale (modified in-place)."
```
- addedInput schema / properties / max_dimension_mm / description
```
Added value: +"Maximum dimension on any axis."
```
- addedInput schema / properties / scale_factor / description
```
Added value: +"Uniform scale multiplier."
```
- addedInput schema / properties / scale_x / description
```
Added value: +"Per-axis X scale factor."
```
- addedInput schema / properties / scale_y / description
```
Added value: +"Per-axis Y scale factor."
```
- addedInput schema / properties / scale_z / description
```
Added value: +"Per-axis Z scale factor."
```
- addedInput schema / properties / target_height_mm / description
```
Added value: +"Desired Z-axis height in mm."
```
Changed6 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / max_dimension_mm / default
```
Removed value: -null
```
- removedInput schema / properties / scale_factor / default
```
Removed value: -null
```
- removedInput schema / properties / scale_x / default
```
Removed value: -null
```
- removedInput schema / properties / scale_y / default
```
Removed value: -null
```
- removedInput schema / properties / scale_z / default
```
Removed value: -null
```
- removedInput schema / properties / target_height_mm / default
```
Removed value: -null
```
First observedv0.1.0Jul 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the destructiveHint=true annotation, the description explicitly states file_path is modified in-place, spells out the mutually exclusive scaling modes ('provide exactly ONE of' and 'Cannot combine uniform and per-axis options'), and explains omitted per-axis behavior. It also discloses the interactive 3D stage side effect and automatic decimation of oversized meshes — context the annotations cannot convey.

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

Conciseness4/5

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

The mode grouping and bullet structure are front-loaded and easy to scan, and the exclusivity rule is stated up front. The 'Args:' block largely duplicates the input schema's parameter descriptions verbatim, which is wasted space, and the 3D-stage paragraph is longer than it needs to be.

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?

For a destructive, in-place mutation with seven parameters and no output schema, the description covers the essential behaviors: mutation scope, mode exclusivity, defaults, and what the user sees on success. It is silent on failure behavior (e.g., invalid mode combination, non-STL input) and whether a backup of the original is kept.

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

Parameters5/5

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

Although schema coverage is already 100%, the description adds meaning the schema cannot express: that target_height_mm, scale_factor, and max_dimension_mm are mutually exclusive and only one may be supplied, that per-axis factors default to 1.0 when omitted, and that uniform and per-axis styles cannot be mixed. That is genuine constraint semantics rather than restatement.

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 description opens with a specific verb and resource: 'Rescale an STL model to meet dimensional targets,' and the mode breakdown makes the operation concrete. It does not, however, distinguish itself from the very similar sibling scale_mesh_to_fit (or split_mesh_to_fit), so an agent must infer which scaling tool applies.

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 gives a clear triggering condition — the model is the wrong size for the build volume or doesn't match desired dimensions — which is more than most siblings offer. It stops short of naming alternatives or exclusions (e.g., when to prefer scale_mesh_to_fit over rescale_model), so the routing decision is left partly implicit.

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

Deploy Server