Skip to main content
Glama

set_printer_model

Destructive

Identify a saved printer's model by name or slicer file so Kiln applies its bed, temperature limits, and slicing profile; use it when the model is not configured and checks are skipped.

Instructions

Tell Kiln which printer model a saved printer is -- by name, or from a slicer file.

Kiln checks every print against the bed it will land on and the
temperatures the machine can take, and slices with the model's own
profile.  All three are read from the printer's model.  With no model
set, those checks are SKIPPED.  Use this as soon as ``kiln_health`` or a
log says the model is not configured.

Two ways to say it -- give exactly one:

* ``printer_model``: any name the catalogue recognises (``"Bambu Lab
  A1"``, ``"bambu_a1"``, ``"MK4"``, ``"K1 Max"``).
* ``slicer_file``: a project the user saved from Bambu Studio,
  OrcaSlicer or PrusaSlicer (File > Save Project), or a printer
  settings file exported from one.  It already names the printer it
  was set up for.  Ask a new user for one instead of asking them to
  look up a model key.

A printer that is NOT in Kiln's catalogue is recorded as the person
names it, with its make (``printer_make="Prusa"``,
``printer_model="Core One L"`` is saved as ``prusa_core_one_l``) and
held to Kiln's generic limits; never substitute a near catalogue model
the person did not name.  A slicer file sets such a printer up more
fully: it states the bed, so Kiln also lays slices out on it and
measures designs against it.  Either way Kiln has no tuned profile for
it and will not move its head.  A model outside the catalogue with no
make (none given, and none implied by the connection) is refused
(``UNKNOWN_MODEL``, with the closest matches); ask who makes it.

Such a printer's bed is recorded here too, and its first print waits
for it (``PRINTER_BED_UNKNOWN``): look up the bed size its maker
publishes (spec page or manual), show the person the size and the page,
and when they say it is right pass ``bed_mm``, ``bed_source`` and
``bed_confirmed=True``.  Never guess the size and never ask the person
to know it.  A catalogue printer's bed is the catalogue's
(``BED_IS_THE_CATALOGUES``).

Args:
    printer_model: The model, in any spelling the catalogue knows.
    slicer_file: Path to a saved slicer project or exported settings.
    printer_name: The saved printer to set.  Omit for the active one.
    printer_make: Who makes the printer ("Prusa", "Anycubic").  Needed
        only for a model outside the catalogue.
    replace: Allow changing a printer that already has a different
        model, or taking a newer file's bed for a printer set up from
        an earlier file, or a new ``bed_mm`` over a recorded one.  Off
        by default: the model decides the limits Kiln checks against,
        so a wrong one is worse than none.
    bed_mm: The bed size ``[x, y, z]`` in mm its maker publishes, for a
        printer outside the catalogue.  With ``printer_model`` only.
    bed_source: Where that size came from: the maker's page (a URL)
        or manual.  Required with ``bed_mm``.
    bed_confirmed: True only once the person has seen the size and its
        source and said it is right.  Never set it on their behalf.

Returns ``applied`` (whether anything changed), the ``printer``, its
``printer_model`` and ``in_catalogue``, and a ``message`` to relay.
When the connected printer reports itself as a different model, it also
returns ``printer_reports`` and the message says so: ask the person
which is right before changing anything.
From a slicer file it also returns ``file`` -- the printer, bed, nozzle
size and material the file states -- and ``notes`` where the file's bed
or nozzle differs from what Kiln holds.  The notes change nothing:
relay them, and if the file's nozzle is the one fitted, record it.

Nothing is written for a model that does not suit the printer's
connection, or over another model unless ``replace`` is set.  Limits an
owner typed for a printer are never written over.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "set_printer_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
bed_mmNoThe bed size ``[x, y, z]`` in mm its maker publishes, for a printer outside the catalogue. With ``printer_model`` only.
replaceNoAllow changing a printer that already has a different model, or taking a newer file's bed for a printer set up from an earlier file, or a new ``bed_mm`` over a recorded one. Off by default: the model decides the limits Kiln checks against, so a wrong one is worse than none. Default: false.
bed_sourceNoWhere that size came from: the maker's page (a URL) or manual. Required with ``bed_mm``.
slicer_fileNoPath to a saved slicer project or exported settings.
printer_makeNoWho makes the printer ("Prusa", "Anycubic"). Needed only for a model outside the catalogue.
printer_nameNoThe saved printer to set. Omit for the active one.
bed_confirmedNoTrue only once the person has seen the size and its source and said it is right. Never set it on their behalf. Default: false.
printer_modelNoThe model, in any spelling the catalogue knows.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.5.1
    • addedInput schema / properties / bed_confirmed
      Added value: +{
      +  "description": "True only once the person has seen the size and its source and said it is right.  Never set it on their behalf. Default: false.",
      +  "title": "Bed Confirmed",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / bed_mm
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "number"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "The bed size ``[x, y, z]`` in mm its maker publishes, for a printer outside the catalogue.  With ``printer_model`` only.",
      +  "title": "Bed Mm"
      +}
    • addedInput schema / properties / bed_source
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Where that size came from: the maker's page (a URL) or manual.  Required with ``bed_mm``.",
      +  "title": "Bed Source"
      +}
    • addedInput schema / properties / printer_make
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Who makes the printer (\"Prusa\", \"Anycubic\").  Needed only for a model outside the catalogue.",
      +  "title": "Printer Make"
      +}
    • addedInput schema / properties / printer_model / description
      Added value: +"The model, in any spelling the catalogue knows."
    • addedInput schema / properties / printer_name / description
      Added value: +"The saved printer to set.  Omit for the active one."
    • changedInput schema / properties / replace / description
      Previous value: -"Default: false."New value: +"Allow changing a printer that already has a different model, or taking a newer file's bed for a printer set up from an earlier file, or a new ``bed_mm`` over a recorded one.  Off by default: the model decides the limits Kiln checks against, so a wrong one is worse than none. Default: false."
    • addedInput schema / properties / slicer_file / description
      Added value: +"Path to a saved slicer project or exported settings."
  2. Addedv1.5.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations it discloses the real consequences: checks are SKIPPED with no model, nothing is written for an unsuitable connection, owner-typed limits are never overwritten, and replace is off by default. It also documents refusal codes (UNKNOWN_MODEL, PRINTER_BED_UNKNOWN, BED_IS_THE_CATALOGUES) and the confirmation flow for bed_mm, which the destructiveHint annotation alone could not convey.

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 prose is front-loaded and logically ordered, but the trailing 'Args:' block duplicates the 100%-covered schema descriptions verbatim, adding length without new information. The body is dense and useful, yet the overall definition is longer than necessary.

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?

For an 8-parameter mutation tool with no output schema, the description covers return fields (applied, printer, in_catalogue, message, printer_reports, file, notes), edge cases, and refusal paths. An agent has everything needed to call it correctly and relay results.

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 100%, so the baseline is 3, but the description adds constraints the schema does not encode: exactly one of printer_model/slicer_file, bed_source required with bed_mm, and bed_confirmed only after the person confirms. The Args block largely restates the schema, limiting the added value.

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?

The opening sentence names a specific verb and resource ('Tell Kiln which printer model a saved printer is') and immediately states the two input modes. It is clearly distinguishable from siblings like register_printer, rename_printer, or select_printer_variant, which do not set the model.

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

Usage Guidelines5/5

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

It gives an explicit trigger ('Use this as soon as kiln_health or a log says the model is not configured') and an explicit alternative path ('Ask a new user for one instead of asking them to look up a model key'). The 'give exactly one' rule for printer_model vs slicer_file is stated outright.

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