Kiln

Overview Schema Source Related Servers Discussions Admin

estimate_print_time

Read-only

Estimate print time, filament length/weight, and layer count by slicing a 3D model or parsing an existing G-code file. Add a material density to include weight in the results.

Instructions

Estimate print time and filament usage for a model.

        Slices the model and parses the G-code for print time, filament
        length/weight, and layer count.

        For **already-sliced** G-code files, pass the ``.gcode`` path
        directly — it will be parsed without re-slicing.

        Weight needs a filament density, which lives on a filament
        profile; Kiln's bundled profiles describe a PRINTER and name no
        filament, so pass ``material`` to get a weight.  Without it the
        weight is reported as absent rather than guessed — a key missing
        from the result means the slicer could not answer it, never that
        the answer is zero.

        **See also:** ``estimate_material_cost`` for weight and cost from
        a mesh with your own price per kg, and ``slice_and_estimate`` for
        a fuller analysis with printability scoring.

        :param file_path: Path to STL/3MF/OBJ or .gcode file.
        :param profile: Optional slicer profile path.
        :param printer_id: Optional printer model ID for bundled profile
            (e.g. ``"bambu_a1"``).  Used when no explicit profile is given.
        :param slicer_path: Optional explicit slicer binary path.
        :param material: Optional filament family (``"PLA"``, ``"PETG"``,
            …) used only as a density source for the weight.
        :returns: Dict with time, filament, and layer estimates.
        :param placement: Where the part goes when the plate still holds
            the last print: ``[x, y]`` in mm, a named region
            (``"front-left"``, ``"centre"``, …) or ``"keep"``.  An
            estimate never refuses because of the plate: with no safe
            spot named the estimate is for the part on an empty plate
            and ``plate_note`` says so.  Not read for a ``.gcode`` input.

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

Input Schema

Name	Required	Description
`profile`	No	Optional slicer profile path. Default: "".
`material`	No	Optional filament family (``"PLA"``, ``"PETG"``, …) used only as a density source for the weight. Default: "".
`file_path`	Yes	Path to STL/3MF/OBJ or .gcode file.
`placement`	No	Where the part goes when the plate still holds the last print: ``[x, y]`` in mm, a named region (``"front-left"``, ``"centre"``, …) or ``"keep"``. An estimate never refuses because of the plate: with no safe spot named the estimate is for the part on an empty plate and ``plate_note`` says so. Not read for a ``.gcode`` input.
`printer_id`	No	Optional printer model ID for bundled profile (e.g. ``"bambu_a1"``). Used when no explicit profile is given. Default: "".
`slicer_path`	No	Optional explicit slicer binary path. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.5.1Nov 5, 2026

addedInput schema / properties / file_path / description
```
Added value: +"Path to STL/3MF/OBJ or .gcode file."
```

changedInput schema / properties / material / description

Previous value: -"Default: \"\"."New value: +"Optional filament family (``\"PLA\"``, ``\"PETG\"``, …) used only as a density source for the weight. Default: \"\"."

addedInput schema / properties / placement / description

Added value: +"Where the part goes when the plate still holds the last print: ``[x, y]`` in mm, a named region (``\"front-left\"``, ``\"centre\"``, …) or ``\"keep\"``.  An estimate never refuses because of the plate: with no safe spot named the estimate is for the part on an empty plate and ``plate_note`` says so.  Not read for a ``.gcode`` input."

changedInput schema / properties / printer_id / description

Previous value: -"Default: \"\"."New value: +"Optional printer model ID for bundled profile (e.g. ``\"bambu_a1\"``).  Used when no explicit profile is given. Default: \"\"."

changedInput schema / properties / profile / description

Previous value: -"Default: \"\"."New value: +"Optional slicer profile path. Default: \"\"."

changedInput schema / properties / slicer_path / description

Previous value: -"Default: \"\"."New value: +"Optional explicit slicer binary path. Default: \"\"."

Changed9 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / material / default
```
Removed value: -""
```
- addedInput schema / properties / material / description
```
Added value: +"Default: \"\"."
```
- addedInput schema / properties / placement
```
Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Placement"
+}
```
- removedInput schema / properties / printer_id / default
```
Removed value: -""
```
- addedInput schema / properties / printer_id / description
```
Added value: +"Default: \"\"."
```
- removedInput schema / properties / profile / default
```
Removed value: -""
```
- addedInput schema / properties / profile / description
```
Added value: +"Default: \"\"."
```
- removedInput schema / properties / slicer_path / default
```
Removed value: -""
```
- addedInput schema / properties / slicer_path / description
```
Added value: +"Default: \"\"."
```
Changed1 schema field changedv1.3.1Aug 19, 2026
- addedInput schema / properties / material
```
Added value: +{
+  "default": "",
+  "title": "Material",
+  "type": "string"
+}
```
First observedv0.1.0Jul 4, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Adds substantial context beyond the readOnly/non-destructive annotations: it explains that weight requires a material density, that absent keys mean the slicer could not answer rather than a zero value, and that placement never causes a refusal but is reflected in plate_note. It does not mention cost/latency of slicing, which would be the final piece.

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?

Purpose and the .gcode shortcut are front-loaded and most sentences earn their place, but structure is irregular: the 'placement' parameter is documented after ':returns:', breaking the docstring ordering, and the material/weight explanation is more verbose than needed.

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

Completeness5/5

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

All six parameters are addressed, the return value is summarized ('Dict with time, filament, and layer estimates') including the plate_note caveat, and the missing output schema is compensated for adequately. Nothing an agent needs to call this correctly is absent.

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

Parameters4/5

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

Schema coverage is already 100%, but the description adds real meaning: material is 'used only as a density source', printer_id applies only when no explicit profile is given, and placement's accepted forms and non-blocking behavior are clarified. This exceeds the baseline 3 expected when the schema carries the parameter docs.

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

Purpose5/5

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

States a specific verb and resource ('Estimate print time and filament usage for a model') and immediately explains the mechanism ('Slices the model and parses the G-code'), plus explicitly names the sibling alternatives in the 'See also' section so an agent can distinguish it from estimate_material_cost and slice_and_estimate.

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?

Gives a concrete routing rule: pass a .gcode path directly for already-sliced files instead of re-slicing. It also names two alternatives with their distinct use cases. No explicit 'when-not-to-use' statement beyond these, which keeps it just below a 5.

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

Deploy Server