Kiln

Overview Schema Source Related Servers Discussions Admin

generate_adaptive_slicing_plan

Read-only

Generate a per-layer slicing plan with variable heights, speeds, and cooling based on detected geometry regions and material constraints for adaptive 3D printing.

Instructions

Generate a per-layer adaptive slicing plan.

Creates a layer-by-layer plan with variable heights, speeds, and
cooling based on detected geometry regions and material constraints.

Args:
    regions: List of region dicts (as ``analyze_model_geometry``
        returns them): ``region_type`` (one of fine_detail, standard,
        bulk, overhang, bridge, top_surface, bottom_surface, thin_wall,
        curved_surface, support_contact), ``z_start_mm``, ``z_end_mm``
        and ``area_pct``.
    material: Material name (PLA, PETG, ABS, etc.).
    model_height_mm: Total model height in mm.
    model_name: Optional model name for record keeping.
    printer: Optional printer identifier.
    nozzle_diameter_mm: Nozzle diameter in mm.  Leave unset for the
        nozzle Kiln has for ``printer`` (or the only printer it knows
        of), else 0.4; the reply's ``nozzle`` says which.
    mode: Adaptive strategy — "balanced" (default), "quality_first",
        "speed_first", or "material_optimized".

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": {
      "regions": "<regions>",
      "material": "<material>",
      "model_height_mm": "<model_height_mm>"
    },
    "name": "generate_adaptive_slicing_plan"
  }
}

Input Schema

Name	Required	Description
`mode`	No	Adaptive strategy — "balanced" (default), "quality_first", "speed_first", or "material_optimized". Default: "balanced".
`printer`	No	Optional printer identifier.
`regions`	Yes	List of region dicts (as ``analyze_model_geometry`` returns them): ``region_type`` (one of fine_detail, standard, bulk, overhang, bridge, top_surface, bottom_surface, thin_wall, curved_surface, support_contact), ``z_start_mm``, ``z_end_mm`` and ``area_pct``.
`material`	Yes	Material name (PLA, PETG, ABS, etc.).
`model_name`	No	Optional model name for record keeping. Default: "".
`model_height_mm`	Yes	Total model height in mm.
`nozzle_diameter_mm`	No	Nozzle diameter in mm. Leave unset for the nozzle Kiln has for ``printer`` (or the only printer it knows of), else 0.4; the reply's ``nozzle`` says which.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.5.1Nov 5, 2026

addedInput schema / properties / material / description

Added value: +"Material name (PLA, PETG, ABS, etc.)."

changedInput schema / properties / mode / description

Previous value: -"Default: \"balanced\"."New value: +"Adaptive strategy — \"balanced\" (default), \"quality_first\", \"speed_first\", or \"material_optimized\". Default: \"balanced\"."

addedInput schema / properties / model_height_mm / description
```
Added value: +"Total model height in mm."
```

changedInput schema / properties / model_name / description

Previous value: -"Default: \"\"."New value: +"Optional model name for record keeping. Default: \"\"."

addedInput schema / properties / nozzle_diameter_mm / description

Added value: +"Nozzle diameter in mm.  Leave unset for the nozzle Kiln has for ``printer`` (or the only printer it knows of), else 0.4; the reply's ``nozzle`` says which."

addedInput schema / properties / printer / description
```
Added value: +"Optional printer identifier."
```

addedInput schema / properties / regions / description

Added value: +"List of region dicts (as ``analyze_model_geometry`` returns them): ``region_type`` (one of fine_detail, standard, bulk, overhang, bridge, top_surface, bottom_surface, thin_wall, curved_surface, support_contact), ``z_start_mm``, ``z_end_mm`` and ``area_pct``."

Changed8 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / mode / default
```
Removed value: -"balanced"
```
- addedInput schema / properties / mode / description
```
Added value: +"Default: \"balanced\"."
```
- removedInput schema / properties / model_name / default
```
Removed value: -""
```
- addedInput schema / properties / model_name / description
```
Added value: +"Default: \"\"."
```
- addedInput schema / properties / nozzle_diameter_mm / anyOf
```
Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedInput schema / properties / nozzle_diameter_mm / default
```
Removed value: -0.4
```
- removedInput schema / properties / nozzle_diameter_mm / type
```
Removed value: -"number"
```
- removedInput schema / properties / printer / default
```
Removed value: -null
```
First observedv0.1.0Jul 4, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds the non-obvious resolution rule that leaving nozzle_diameter_mm unset falls back to Kiln's nozzle for the given printer (or 0.4) and that the reply's ``nozzle`` field reports which was used. "Creates a plan" reads as generating a computed result rather than persisting state, so it is not in tension with readOnlyHint. It stops short of saying whether the plan is returned inline or stored.

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 two sentences are well-formed and front-loaded, but the entire Args section duplicates a schema that is already 100% documented, roughly doubling length without adding information. Trimming the argument list to only the nozzle fallback note would preserve all value.

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

Completeness3/5

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

With no output schema and seven parameters, the description should describe what the returned plan looks like, since it is the tool's whole product; instead it only alludes to "the reply's ``nozzle``." The expected handoff from analyze_model_geometry is implied but the region dict shape is documented, which is the strongest completeness signal present. Adequate, but a plan-consuming agent is left guessing at the output structure.

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 every parameter is already documented in the schema, and the Args block largely restates those same sentences verbatim. The one genuinely useful addition — the nozzle fallback chain — is also present in the schema description, so the prose adds no semantics beyond structured data. 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 leads with a specific verb and resource — "Generate a per-layer adaptive slicing plan" — and immediately specifies what the plan varies (heights, speeds, cooling) and what it derives from (geometry regions, material constraints). That is clear enough to know it plans rather than slices or estimates. It does not, however, distinguish itself from near siblings such as quick_adaptive_plan or export_adaptive_slicer_config, which an agent would likely confuse it with.

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: the regions argument is documented as "as analyze_model_geometry returns them," which signals the prerequisite upstream call. There is no explicit statement of when to prefer this over quick_adaptive_plan, when a full per-layer plan is warranted versus a faster summary, or any exclusion conditions.

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

Deploy Server