Kiln

Overview Schema Source Related Servers Discussions Admin

predict_print_failure

Read-only

Analyze mesh geometry to predict common 3D printing failures such as thin walls, unsupported bridges, and overhangs; return a risk score with detailed fixes.

Instructions

Predict common 3D printing failure modes from mesh geometry.

Analyzes the mesh for thin walls, long unsupported bridges,
severe overhangs, top-heavy geometry, small features, and
non-manifold issues.  Returns a risk score (0-100) and
per-failure details with fix suggestions.

The thin-wall floor follows the nozzle: two lines of it, so 0.8 mm for
a 0.4 mm nozzle and 1.2 mm for a 0.6.  The answer says which nozzle it
was judged for and where that size came from.

:param file_path: Path to mesh file (.stl, .obj, .glb, or .3mf).
:param min_wall_mm: Minimum printable wall thickness.  Leave it out to
    use two lines of the nozzle.
:param max_bridge_mm: Maximum unsupported bridge length (default 15).
:param max_overhang_deg: Maximum overhang angle before failure (default 55).
:param printer_id: The printer the part is for.  Left out, the only
    printer Kiln knows of stands in.
:param nozzle_mm: The nozzle fitted, when you know it.  Left out, the
    nozzle on record for the printer, then the printer's own setting,
    then its stock size.
:returns: Dict with verdict, risk score, failure list, the wall floor
    used and the nozzle it was judged for.

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

Input Schema

Name	Required	Description
`file_path`	Yes	Path to mesh file (.stl, .obj, .glb, or .3mf).
`nozzle_mm`	No	The nozzle fitted, when you know it. Left out, the nozzle on record for the printer, then the printer's own setting, then its stock size.
`printer_id`	No	The printer the part is for. Left out, the only printer Kiln knows of stands in.
`min_wall_mm`	No	Minimum printable wall thickness. Leave it out to use two lines of the nozzle.
`max_bridge_mm`	No	Maximum unsupported bridge length (default 15). Default: 15.0.
`max_overhang_deg`	No	Maximum overhang angle before failure (default 55). Default: 55.0.

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 mesh file (.stl, .obj, .glb, or .3mf)."

changedInput schema / properties / max_bridge_mm / description

Previous value: -"Default: 15.0."New value: +"Maximum unsupported bridge length (default 15). Default: 15.0."

changedInput schema / properties / max_overhang_deg / description

Previous value: -"Default: 55.0."New value: +"Maximum overhang angle before failure (default 55). Default: 55.0."

addedInput schema / properties / min_wall_mm / description

Added value: +"Minimum printable wall thickness.  Leave it out to use two lines of the nozzle."

addedInput schema / properties / nozzle_mm / description

Added value: +"The nozzle fitted, when you know it.  Left out, the nozzle on record for the printer, then the printer's own setting, then its stock size."

addedInput schema / properties / printer_id / description

Added value: +"The printer the part is for.  Left out, the only printer Kiln knows of stands in."

Changed9 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / max_bridge_mm / default
```
Removed value: -15
```
- addedInput schema / properties / max_bridge_mm / description
```
Added value: +"Default: 15.0."
```
- removedInput schema / properties / max_overhang_deg / default
```
Removed value: -55
```
- addedInput schema / properties / max_overhang_deg / description
```
Added value: +"Default: 55.0."
```
- addedInput schema / properties / min_wall_mm / anyOf
```
Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedInput schema / properties / min_wall_mm / default
```
Removed value: -0.8
```
- removedInput schema / properties / min_wall_mm / type
```
Removed value: -"number"
```
- addedInput schema / properties / nozzle_mm
```
Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Nozzle Mm"
+}
```
- addedInput schema / properties / printer_id
```
Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Printer Id"
+}
```
First observedv0.1.0Jul 4, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description goes beyond that with real behavioral context: the 0-100 risk score, per-failure detail with fix suggestions, and an explicit fallback chain for how the nozzle size is resolved and reported back. It does not mention cost, runtime, or whether geometry is re-analyzed per call, which is why it is not a 5.

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 opening paragraph is well front-loaded and the thin-wall/nozzle explanation is high-value. However, the ':param ...' block largely restates text already present verbatim in the input schema descriptions, adding length without adding information and diluting the signal.

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 ':returns:' line properly carries the burden, naming verdict, risk score, failure list, wall floor, and judged nozzle. Fallback behavior for the optional parameters is covered, and read-only annotations cap the safety disclosure needed. The remaining gap is sibling disambiguation, which matters given several overlapping print-analysis tools.

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?

Schema coverage is 100%, so the baseline is 3, and the description earns more: it explains the derivation of min_wall_mm as two nozzle lines with concrete 0.8 mm / 1.2 mm examples, and it spells out the precedence chain for nozzle_mm and printer_id defaults. That is meaning an agent could not recover from the schema alone.

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?

States a specific verb and resource ("Predict common 3D printing failure modes from mesh geometry") and enumerates the exact failure modes analyzed (thin walls, bridges, overhangs, top-heavy geometry, small features, non-manifold), plus the return shape. It does not distinguish itself from near-name siblings such as predict_print_failure_risk, analyze_printability, or predict_print_settings, which keeps it below a 5.

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: an agent can infer this is a pre-print geometric check, and the parameter defaults hint at the pre-slicing stage. There is no explicit statement of when to call this versus analyze_printability or predict_print_failure_risk, nor any exclusion or prerequisite (e.g. mesh must exist, orientation assumed fixed).

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

Deploy Server