Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

set_temperature

Destructive

Set target hotend and heated bed temperatures on a 3D printer; pass 0 to turn a heater off or omit a value to leave it unchanged.

Instructions

Set the target temperature for the hotend (tool) and/or heated bed.

Args:
    tool_temp: Target hotend temperature in Celsius.  Pass ``0`` to turn
        the heater off.  Omit or pass ``null`` to leave unchanged.
    bed_temp: Target bed temperature in Celsius.  Pass ``0`` to turn
        the heater off.  Omit or pass ``null`` to leave unchanged.
    printer_name: Which printer to heat.  Omit for the default printer.
        The safety ceiling follows the named machine; a printer with no
        declared model is held to the generic floor — set its model with
        ``set_printer_model`` (or ``add_safety_profile``) when that floor
        refuses a temperature.

At least one of ``tool_temp`` or ``bed_temp`` must be provided.

Common PLA temperatures: tool 200-210C, bed 60C.
Common PETG temperatures: tool 230-250C, bed 80-85C.
Common ABS temperatures: tool 240-260C, bed 100-110C.

Branch on ``outcome`` — one field, three values, the same shape
``start_print`` uses for ``print_start``:

- ``"confirmed"``: the printer, in a report AFTER the command, shows the
  effect. Reported per heater under ``tool`` and ``bed``.
- ``"accepted"``: the command was sent and not refused, and the printer
  has not shown the effect yet. Normal on a quiet printer. Read
  ``printer_status()`` before building on it.
- ``"failed"``: the printer's interface refused the command.

``accepted`` (the boolean) keeps its old meaning: sent, not refused. It
is never proof the printer acted. ``success`` is ``False`` only for
``"failed"``.

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_temperature"
  }
}

Input Schema

NameRequiredDescriptionDefault
bed_tempNoTarget bed temperature in Celsius. Pass ``0`` to turn the heater off. Omit or pass ``null`` to leave unchanged.
tool_tempNoTarget hotend temperature in Celsius. Pass ``0`` to turn the heater off. Omit or pass ``null`` to leave unchanged.
printer_nameNoWhich printer to heat. Omit for the default printer. The safety ceiling follows the named machine; a printer with no declared model is held to the generic floor — set its model with ``set_printer_model`` (or ``add_safety_profile``) when that floor refuses a temperature.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • addedInput schema / properties / bed_temp / description
      Added value: +"Target bed temperature in Celsius.  Pass ``0`` to turn the heater off.  Omit or pass ``null`` to leave unchanged."
    • addedInput schema / properties / printer_name / description
      Added value: +"Which printer to heat.  Omit for the default printer. The safety ceiling follows the named machine; a printer with no declared model is held to the generic floor — set its model with ``set_printer_model`` (or ``add_safety_profile``) when that floor refuses a temperature."
    • addedInput schema / properties / tool_temp / description
      Added value: +"Target hotend temperature in Celsius.  Pass ``0`` to turn the heater off.  Omit or pass ``null`` to leave unchanged."
  2. Changed3 schema fields changedv1.5.0
    • removedInput schema / properties / bed_temp / default
      Removed value: -null
    • removedInput schema / properties / printer_name / default
      Removed value: -null
    • removedInput schema / properties / tool_temp / default
      Removed value: -null
  3. Changed1 schema field changedv1.3.1
    • addedInput schema / properties / printer_name
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Printer Name"
+}
  4. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Without relying on the annotations, the description explains the safety ceiling per named machine, distinguishes the three outcome values (confirmed/accepted/failed), and warns that the accepted boolean is "never proof the printer acted" and that success is False only for failed. That is real behavioral context an agent cannot get from destructiveHint=false/true alone, and it is consistent with destructiveHint=true.

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?

Front-loaded with the one-sentence purpose, then args, precondition, reference temperatures, and outcome semantics in a scannable order. The Args block repeats the schema descriptions verbatim, which is wasted length, but nothing else is filler.

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?

No output schema exists, and the description compensates by documenting the outcome/success/accepted return fields, so an agent knows how to interpret the response. For a three-parameter mutation tool with annotations present, this is essentially complete, with only the failure-recovery path left implicit.

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 genuine meaning to the values: 0 turns the heater off, null/omitted leaves it unchanged, and typical PLA/PETG/ABS setpoints give the agent sensible magnitudes to choose. The per-parameter text largely duplicates the schema descriptions, which caps this below 5.

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 ("Set the target temperature for the hotend (tool) and/or heated bed") with the scope of what is affected, which cleanly separates it from siblings like set_fan, set_speed_profile or set_printer_light.

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 hard precondition ("At least one of tool_temp or bed_temp must be provided"), practical material-based target ranges for PLA/PETG/ABS, and routes the agent to set_printer_model or add_safety_profile when the generic safety floor refuses a temperature. It does not explicitly say when to prefer this over adjacent tools such as start_print, but coverage is otherwise strong.

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