Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

set_fan

Destructive

Set a 3D printer fan speed from 0-100% to add cooling for bridges and overhangs or manage chamber heat on supported printers.

Instructions

Set the speed of a printer fan.

``percent`` has no default on purpose.  Measured 2026-09-18 on an A1:
a call meant to turn the fan OFF reached Kiln with no ``percent`` at
all (the caller's own argument name had been dropped before the
request arrived), the old default of 100 ran the fan flat out, and
the answer confirmed it.  A setpoint the caller did not send is
refused, never guessed.

Supported on Bambu Lab, OctoPrint, Moonraker/Klipper printers, and
Elegoo's Centauri Carbon (FDM). Prusa Link has no raw G-code endpoint, so
fan control isn't available there (a known limitation of Prusa Link
itself). An Elegoo machine with no part-cooling fan is refused.

Args:
    node: Which fan to set. ``"part"`` (part-cooling / model fan, the
        one that cools each layer) works on every supported printer.
        ``"aux"`` (auxiliary / big fan) and ``"chamber"`` (chamber /
        exhaust fan) are Bambu-only — generic Marlin/Klipper firmware has
        no standard auxiliary or chamber fan Kiln can address without
        knowing that machine's own G-code macros. Defaults to ``"part"``.
    percent: Fan speed 0-100. ``0`` turns the fan off, ``100`` is full
        speed. Required.

Use this to add cooling for bridges and overhangs (part fan), or — on
Bambu — pull heat with the auxiliary fan or run the chamber/exhaust fan
for materials like ABS/ASA. The Bambu chamber fan only exists on
enclosed models — X1 Carbon, X1E, P1S, P2S, H2S — not on open-frame
models (A1, A1 Mini, A2L, P1P), where a chamber command is a no-op. The
printer's own thermal management may override a manual fan speed during
a print.

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. For a Bambu, that fan's reported level matches.
- ``"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

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": {
      "percent": "<percent>"
    },
    "name": "set_fan"
  }
}

Input Schema

NameRequiredDescriptionDefault
nodeNoWhich fan to set. ``"part"`` (part-cooling / model fan, the one that cools each layer) works on every supported printer. ``"aux"`` (auxiliary / big fan) and ``"chamber"`` (chamber / exhaust fan) are Bambu-only — generic Marlin/Klipper firmware has no standard auxiliary or chamber fan Kiln can address without knowing that machine's own G-code macros. Defaults to ``"part"``. Default: "part".
percentYesFan speed 0-100. ``0`` turns the fan off, ``100`` is full speed. Required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • changedInput schema / properties / node / description
      Previous value: -"Default: \"part\"."New value: +"Which fan to set. ``\"part\"`` (part-cooling / model fan, the one that cools each layer) works on every supported printer. ``\"aux\"`` (auxiliary / big fan) and ``\"chamber\"`` (chamber / exhaust fan) are Bambu-only — generic Marlin/Klipper firmware has no standard auxiliary or chamber fan Kiln can address without knowing that machine's own G-code macros. Defaults to ``\"part\"``. Default: \"part\"."
    • addedInput schema / properties / percent / description
      Added value: +"Fan speed 0-100. ``0`` turns the fan off, ``100`` is full speed. Required."
  2. Changed4 schema fields changedv1.5.0
    • removedInput schema / properties / node / default
      Removed value: -"part"
    • addedInput schema / properties / node / description
      Added value: +"Default: \"part\"."
    • removedInput schema / properties / percent / default
      Removed value: -100
    • addedInput schema / required
      Added value: +[
+  "percent"
+]
  3. Addedv1.2.0

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations, the description explains that a missing percent is refused rather than defaulted, documents printer support and refusal cases, notes that the printer's thermal management may override manual fan speed, and defines the three outcome values and the accepted boolean semantics. This is substantial behavioral context for a write operation whose annotations only say it is not read-only, is destructive, and is not open-world.

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 description is front-loaded with purpose and organized into support, argument, usage, and outcome sections. However, it is quite long, repeats the schema's parameter descriptions almost verbatim, and includes an incident narrative about the old default that, while relevant, is more verbose 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?

There is no output schema, so the description carries the burden of explaining return semantics, and it does so thoroughly with the confirmed/accepted/failed outcome values and the accepted boolean. It also covers supported printers, unsupported cases, and thermal override behavior, leaving little an agent needs to infer before calling the tool.

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%, and the description's Args section largely repeats the node and percent descriptions already present in the schema. It adds some useful rationale for why percent is required and never guessed, but most parameter meaning is already supplied by the structured schema, so the baseline of 3 is appropriate.

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 first sentence states a specific verb and resource: 'Set the speed of a printer fan.' The description makes the fan-specific scope clear and later distinguishes part, auxiliary, and chamber fans, but it does not explicitly name sibling alternatives such as set_speed_percent or send_gcode, so sibling differentiation is only implicit.

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?

It gives clear usage contexts, including cooling bridges and overhangs with the part fan and using auxiliary or chamber fans for ABS/ASA on Bambu printers. It also gives explicit exclusions: Prusa Link is unsupported, Elegoo machines without a part-cooling fan are refused, and chamber commands are no-ops on open-frame Bambu models. It stops short of naming alternative tools for overlapping tasks.

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