Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

build_material_overrides

Read-only

Resolve a material or product into printer-specific slicer overrides for temperature, melt rate, and cooling, so you can inspect or pin them during reslicing.

Instructions

The slicer settings a material gets on a printer: temperatures, melt rate, cooling.

Every slicing door applies these itself when it is told the material --
``material=`` on ``slice_model``, ``slice_and_print``,
``reslice_with_overrides``, ``run_quick_print``, ``run_reslice_and_print``
and ``kiln slice`` -- so naming the material is all a slice needs.  This
tool shows what that will be and why, from the same resolver
(:mod:`kiln.slicer_material`): a product's own figures when you name one
(``"bambu_tpu_95a"``), else Kiln's settings for the material on this
printer, else the middle of the material's range, never above what the
printer is rated for.  The melt-rate ceiling
(``filament_max_volumetric_speed``) slows every feature of the print to
suit the material, the outer wall and the first layer included.

Its ``overrides`` can still be passed to ``reslice_with_overrides`` to
pin them; a setting passed that way is the caller's, and a slice leaves
it alone.

Example::

    build_material_overrides("tpu", "bambu_a1")
    # overrides: temperature 225, bed_temperature 50, max_fan_speed 50, ...

Args:
    material_id: Material (``"petg"``, ``"tpu"``, ``"PA-CF"``) or a
        product (``"bambu_tpu_95a"``).
    printer_id: Printer model, for its own settings and limits.
        Omitted, the material's own.

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": {
      "material_id": "<material_id>"
    },
    "name": "build_material_overrides"
  }
}

Input Schema

NameRequiredDescriptionDefault
printer_idNoPrinter model, for its own settings and limits. Omitted, the material's own.
material_idYesMaterial (``"petg"``, ``"tpu"``, ``"PA-CF"``) or a product (``"bambu_tpu_95a"``).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / material_id / description
      Added value: +"Material (``\"petg\"``, ``\"tpu\"``, ``\"PA-CF\"``) or a product (``\"bambu_tpu_95a\"``)."
    • addedInput schema / properties / printer_id / description
      Added value: +"Printer model, for its own settings and limits. Omitted, the material's own."
  2. Changed1 schema field changedv1.5.0
    • removedInput schema / properties / printer_id / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare a safe read (readOnlyHint true, destructiveHint false, openWorldHint false), yet the description still adds substantial behavior: the three-step resolution precedence (product figures, then Kiln settings for material on this printer, then middle of range, capped by printer rating), the melt-rate ceiling applied to every feature including outer wall and first layer, and the pinning semantics where a caller-supplied setting is left alone by a later slice.

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?

Core claim is front-loaded and the resolution rules plus the example earn their space by clarifying output shape. It is somewhat longer than needed and carries RST markup (double backticks, :mod:) that is noise in a tool description, and the 'naming the material is all a slice needs' point is made at more length than required.

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?

No output schema exists, and the description compensates with a concrete example of the returned overrides (temperature 225, bed_temperature 50, max_fan_speed 50) as well as the derivation logic and the downstream use of the result. For a two-parameter, read-only resolver this is complete enough to call correctly without guessing.

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 the two parameters are already documented and the description's Args block largely restates them verbatim. It does add some meaning via the fallback chain that explains what printer_id omission yields in practice, but that overlap with the schema caps the added value at the baseline.

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?

Opens with a specific verb+resource statement — the slicer settings a material gets on a printer (temperatures, melt rate, cooling) — and 'This tool shows what that will be and why' pins it as an inspection/resolution tool. It is clearly separable from siblings like slice_model and reslice_with_overrides, which it names as consumers rather than equivalents.

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?

Explains that every slicing door already applies these settings when told the material, so this tool is for seeing what will be applied and why, not a prerequisite for slicing — that implicitly routes the agent away from calling it for a plain slice. It also states the overrides can be passed to reslice_with_overrides to pin them. The when-to-use routing is implied by these relationships rather than stated as an explicit 'use this when you need to know X'.

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