Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

auto_orient_model

Destructive

Evaluates rotations of an STL or OBJ mesh to find the best print orientation, ranking candidates by support volume, overhangs, bed contact and height. Optionally applies the best turn and writes the reoriented mesh.

Instructions

Find the optimal print orientation for a 3D model.

        Evaluates multiple rotations of the model, ranks them, and
        reports each candidate's bed contact, support volume, print
        height and overhang share.  Candidates come in the order Kiln
        ranks them for this account; each candidate's ``score`` is its
        bed-contact percentage, so a later candidate can score higher
        than the best.  ``message`` says what the best turn changes
        (support, overhangs, bed contact, height) or that the part
        already sits best.  With ``apply``, writes the reoriented mesh
        to ``output_path`` (a file already there is replaced).

        Args:
            file_path: Path to an STL or OBJ mesh file.
            candidates: Number of candidate orientations to evaluate
                (default 24).
            nozzle_diameter: Printer nozzle diameter in mm (default 0.4).
            apply: If True, apply the best orientation and write the
                reoriented STL to disk.
            output_path: Output path for the reoriented STL.  Only used
                when ``apply`` is True.  Defaults to
                ``<input>_oriented.stl``.

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": "auto_orient_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
applyNoIf True, apply the best orientation and write the reoriented STL to disk. Default: false.
file_pathYesPath to an STL or OBJ mesh file.
candidatesNoNumber of candidate orientations to evaluate (default 24). Default: 24.
output_pathNoOutput path for the reoriented STL. Only used when ``apply`` is True. Defaults to ``<input>_oriented.stl``.
nozzle_diameterNoPrinter nozzle diameter in mm (default 0.4). Default: 0.4.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.5.1
    • changedInput schema / properties / apply / description
      Previous value: -"Default: false."New value: +"If True, apply the best orientation and write the reoriented STL to disk. Default: false."
    • changedInput schema / properties / candidates / description
      Previous value: -"Default: 24."New value: +"Number of candidate orientations to evaluate (default 24). Default: 24."
    • addedInput schema / properties / file_path / description
      Added value: +"Path to an STL or OBJ mesh file."
    • changedInput schema / properties / nozzle_diameter / description
      Previous value: -"Default: 0.4."New value: +"Printer nozzle diameter in mm (default 0.4). Default: 0.4."
    • addedInput schema / properties / output_path / description
      Added value: +"Output path for the reoriented STL.  Only used when ``apply`` is True.  Defaults to ``<input>_oriented.stl``."
  2. Changed7 schema fields changedv1.5.0
    • removedInput schema / properties / apply / default
      Removed value: -false
    • addedInput schema / properties / apply / description
      Added value: +"Default: false."
    • removedInput schema / properties / candidates / default
      Removed value: -24
    • addedInput schema / properties / candidates / description
      Added value: +"Default: 24."
    • removedInput schema / properties / nozzle_diameter / default
      Removed value: -0.4
    • addedInput schema / properties / nozzle_diameter / description
      Added value: +"Default: 0.4."
    • removedInput schema / properties / output_path / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

The destructiveHint=true annotation is backed up by concrete detail: with apply, the reoriented mesh is written to output_path, and an existing file at that path is replaced, so the agent knows the write path is destructive. It also discloses the default output name (<input>_oriented.stl) and that output_path is ignored unless apply is true, which goes beyond the annotations. It does not cover failure modes such as missing or unreadable input files, or compute cost for large candidate counts.

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 description is front-loaded with purpose and return-value semantics, then a clean Args block, so the structure is easy to scan. The Args block duplicates schema content almost verbatim, which is redundant for a 100%-covered schema and slightly inflates length. Overall it is reasonably tight but not free of boilerplate.

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 carries the job of explaining results, and it does that well: candidate ordering, the meaning of score (bed-contact percentage, and that a later candidate can score higher than the best), and what message reports. The apply/output_path behavior and overwrite risk are also covered. What is missing is any hint about how expensive the operation is or how errors surface, which matters for a tool with a tunable search budget.

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 coverage is 100% and every parameter already carries a description, so the description's Args block largely restates the schema. It does add a little meaning: output_path is conditional on apply, and the default naming convention is spelled out. The semantics of candidates (number of orientations evaluated) and nozzle_diameter (used to judge printability) are not expanded beyond the schema text, so the baseline 3 applies.

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 gives a specific verb and resource (find the optimal print orientation for a 3D model) and explains the mechanism: evaluate rotations, rank them, and report bed contact, support volume, height, and overhang. It never distinguishes itself from closely named siblings such as optimize_print_orientation, check_orientation, or rotate_model, which leaves a real risk of tool-selection ambiguity.

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

Usage Guidelines3/5

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

Usage is only implied by the purpose statement: you use it when you want the best print orientation. There is no explicit when-to-use versus when-not-to-use guidance and no named alternative, despite several closely related siblings. In particular, it never says how this differs from optimize_print_orientation or when to rotate manually instead.

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

Deploy Server

Other Tools