Skip to main content
Glama

ams_filament_drying

Destructive

Start or stop an active filament-drying cycle on Bambu AMS 2 Pro or AMS HT units, with temperature ceiling checks before commands are sent.

Instructions

Start or stop an AMS 2 Pro / AMS HT active dry cycle.

Bambu printers with an AMS 2 Pro or AMS HT dry filament in place.
This controls that dryer.

To START (``mode=1``): set ``temp_c`` (drying temperature),
``duration_min`` (> 0), and ``cooling_temp_c`` -- which must be
>= 45, or the printer silently ignores the command.  A start is
checked against the unit's own ceiling (AMS 2 Pro 65 C, AMS HT 85 C)
before it is sent; when Kiln cannot run that check, nothing is sent and
the answer says why.  To STOP (``mode=0``): only ``ams_id`` is needed,
and a stop is always sent.

Only Bambu printers with an AMS 2 Pro / AMS HT support this; other
printers and plain AMS / AMS Lite units return an error.

:param ams_id: AMS unit index (0-based).
:param mode: 1 to start drying, 0 to stop.
:param duration_min: Dry-cycle length in minutes (> 0 to start).
:param temp_c: Drying temperature in C (required to start).  A value
    above the unit's own drying ceiling is refused, never lowered;
    the refusal names the ceiling.
:param cooling_temp_c: Cooldown temperature in C (>= 45 to start).
:param humidity: Target relative humidity in percent, when the unit
    supports a humidity target.
:param rotate_tray: Whether the unit turns the spool during the cycle
    (``True``/``False``); leave unset to keep the unit's own setting.
:param printer_name: Target printer.  Omit for the default printer.
:returns: Dict with the dispatched command and a status message.

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": {
      "ams_id": "<ams_id>",
      "mode": "<mode>"
    },
    "name": "ams_filament_drying"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeYes1 to start drying, 0 to stop.
ams_idYesAMS unit index (0-based).
temp_cNoDrying temperature in C (required to start). A value above the unit's own drying ceiling is refused, never lowered; the refusal names the ceiling.
humidityNoTarget relative humidity in percent, when the unit supports a humidity target.
rotate_trayNoWhether the unit turns the spool during the cycle (``True``/``False``); leave unset to keep the unit's own setting.
duration_minNoDry-cycle length in minutes (> 0 to start). Default: 0.
printer_nameNoTarget printer. Omit for the default printer.
cooling_temp_cNoCooldown temperature in C (>= 45 to start).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.5.1
    • addedInput schema / properties / ams_id / description
      Added value: +"AMS unit index (0-based)."
    • addedInput schema / properties / cooling_temp_c / description
      Added value: +"Cooldown temperature in C (>= 45 to start)."
    • changedInput schema / properties / duration_min / description
      Previous value: -"Default: 0."New value: +"Dry-cycle length in minutes (> 0 to start). Default: 0."
    • addedInput schema / properties / humidity / description
      Added value: +"Target relative humidity in percent, when the unit supports a humidity target."
    • addedInput schema / properties / mode / description
      Added value: +"1 to start drying, 0 to stop."
    • addedInput schema / properties / printer_name / description
      Added value: +"Target printer.  Omit for the default printer."
    • addedInput schema / properties / rotate_tray / description
      Added value: +"Whether the unit turns the spool during the cycle (``True``/``False``); leave unset to keep the unit's own setting."
    • addedInput schema / properties / temp_c / description
      Added value: +"Drying temperature in C (required to start).  A value above the unit's own drying ceiling is refused, never lowered; the refusal names the ceiling."
  2. Addedv1.5.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the destructiveHint=true / openWorldHint=false annotations, the description discloses real behavioral traits: the printer silently ignores a start when cooling_temp_c < 45, starts are pre-validated against unit ceilings (65 C / 85 C), nothing is dispatched when that check cannot run, and stops are always sent. Silent-failure modes and the hardware gate are exactly what an agent needs before issuing a mutation.

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 purpose and cleanly partitioned into START and STOP blocks, which is the right structure. There is some duplication: the temperature ceiling and the 'refused, never lowered' rule appear both in the START paragraph and again under :param temp_c:.

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 required-vs-optional parameters per mode, hardware gating, validation failure behavior, and the return shape ('dict with the dispatched command and a status message'). An agent has enough to call it correctly on the first attempt.

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 schema already carries per-parameter meaning, and the description largely restates it verbatim (temp_c ceiling, cooling_temp_c >= 45, rotate_tray unset behavior). The mode=1/mode=0 pairing of required parameters adds mild operational context, but nothing materially new beyond the schema.

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 pair (start or stop) and a specific resource (an AMS 2 Pro / AMS HT active dry cycle), then clarifies 'This controls that dryer.' An agent can separate this from siblings like drying_advisor (advice) or ams_status (status) without opening either schema.

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 when-to-use context: only Bambu printers with AMS 2 Pro or AMS HT, and it splits the two modes into explicit START and STOP recipes. It does not name alternative tools (e.g. drying_advisor for guidance), so routing is inferred rather than stated, but the operating conditions are unambiguous.

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