Skip to main content
Glama

set_printer_light

Destructive

Control a Bambu Lab printer's chamber or work LED: turn it on, off, or flashing to improve camera visibility, signal print completion, or darken overnight prints.

Instructions

Control the printer's LED lights (Bambu Lab printers only).

Args:
    node: Which light to control — ``"chamber_light"`` (main
        illumination) or ``"work_light"`` (nozzle area).
        Defaults to ``"chamber_light"``.
    mode: Light mode — ``"on"``, ``"off"``, or ``"flashing"``.
        Required: a call that arrives without it is refused rather
        than turned on (the same rule as ``set_fan``'s ``percent``).

Use this to improve camera visibility, signal print completion
(flashing), or turn lights off for overnight prints.

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, the light report lists that node in that mode.
- ``"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": {
      "mode": "<mode>"
    },
    "name": "set_printer_light"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeYesLight mode — ``"on"``, ``"off"``, or ``"flashing"``. Required: a call that arrives without it is refused rather than turned on (the same rule as ``set_fan``'s ``percent``).
nodeNoWhich light to control — ``"chamber_light"`` (main illumination) or ``"work_light"`` (nozzle area). Defaults to ``"chamber_light"``. Default: "chamber_light".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / mode / description
      Added value: +"Light mode — ``\"on\"``, ``\"off\"``, or ``\"flashing\"``. Required: a call that arrives without it is refused rather than turned on (the same rule as ``set_fan``'s ``percent``)."
    • changedInput schema / properties / node / description
      Previous value: -"Default: \"chamber_light\"."New value: +"Which light to control — ``\"chamber_light\"`` (main illumination) or ``\"work_light\"`` (nozzle area). Defaults to ``\"chamber_light\"``. Default: \"chamber_light\"."
  2. Changed4 schema fields changedv1.5.0
    • removedInput schema / properties / mode / default
      Removed value: -"on"
    • removedInput schema / properties / node / default
      Removed value: -"chamber_light"
    • addedInput schema / properties / node / description
      Added value: +"Default: \"chamber_light\"."
    • addedInput schema / required
      Added value: +[
      +  "mode"
      +]
  3. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing return semantics: the three-valued "outcome" (confirmed/accepted/failed), what each means in terms of printer reports, and that the legacy "accepted" boolean is never proof the printer acted while "success" is False only for failed. Since no output schema exists, this disclosure carries the full burden and does so precisely.

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 outcome section is front-loaded and valuable, but the Args block duplicates parameter text already present in the schema, which is wasted space for an agent that receives both. Structure is otherwise clear with no filler sentences.

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 a two-parameter actuator with no output schema, the definition supplies the platform restriction, defaults, required-argument behavior, and a full interpretation of the response fields an agent must branch on. Nothing needed to call it correctly or interpret the result is missing.

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 coverage is 100%, so the baseline is 3. The Args block restates the schema descriptions nearly verbatim (node values, mode values, mode required) rather than adding new meaning such as enum constraints or edge cases like sending "flashing" to a printer without that capability.

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 — "Control the printer's LED lights" — plus a platform restriction ("Bambu Lab printers only") that no sibling tool covers, which cleanly separates it from adjacent actuator tools like set_fan, set_temperature, and set_speed_percent.

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 three concrete use cases (camera visibility, flashing to signal print completion, lights off overnight) that make the when-to-use condition obvious. It does not name a sibling alternative or state an explicit when-not-to-use case, but for a niche actuator the context is sufficient.

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