Skip to main content
Glama

ams_status

Read-only

Inspect all AMS trays to verify loaded filament type, color, remaining amount, RFID, and humidity before printing or selecting AMS mappings.

Instructions

Full AMS hardware dump — all trays, humidity, RFID (Bambu Lab only).

For just the currently-active material, use ``get_active_material``
instead. For Kiln's software material tracker, use ``get_material``.

Returns what's loaded in each AMS tray: filament type, color, remaining
percentage, RFID tag, temperature ranges, and humidity.

Each tray carries its unit's own ``slot`` (0-3), the printer's
``tray_id`` for it (``unit * 4 + slot`` on a chained unit, the unit id
itself on an AMS HT) and Studio's ``name`` (``A1``…``D4``, ``HT-A``);
each unit carries its ``name`` (``A``, ``HT-B``).  ``feeding`` is the
tray feeding the nozzle -- ``{tray_id, unit, slot, name, source}``, or
``None`` when nothing feeds -- and ``feeding_source`` says which field
of the printer's report it came from.  The raw ``tray_now`` is kept as
sent: ``"254"`` is the external spool,
``"255"`` no tray.  A1 / AMS Lite reports may keep ``tray_now`` at
``"255"`` while exposing loaded AMS trays and selected/target tray
fields such as ``tray_pre`` or ``tray_tar``.  The ``ams_exist_bits`` and
``tray_exist_bits`` fields are bitmasks showing which AMS units and
trays are physically present.

Use this to check filament levels before printing, verify the correct
material is loaded, or select the right ``ams_mapping`` for
``start_print()``.

This dump carries no fault line of its own.  To follow a print, poll
``printer_status(detail="lite")``: it reports the run state and every
fault code under ``faults``.  A fault the printer stops for on a
watched print also rides this and every other tool result as
``printer_fault`` while it stands.

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": "ams_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/non-destructive; the description adds substantial behavior beyond them: the platform limitation ("Bambu Lab only"), the exact field set returned, the ``tray_id`` computation rule (``unit * 4 + slot``), sentinel semantics for ``tray_now`` ("254" external spool, "255" no tray), AMS Lite quirks, and the bitmask meaning of ``ams_exist_bits``/``tray_exist_bits``. It also discloses a real caveat — this dump carries no fault line of its own, but a standing fault rides along as ``printer_fault``.

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?

Well front-loaded: purpose, then alternatives, then usage, then return details, then the fault caveat. Every sentence carries information, though the mid-section field-by-field explanation (``slot``/``tray_id``/``name`` derivation, A1 ``tray_pre``/``tray_tar`` edge case) is dense and could be tightened without losing meaning.

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 must carry the return contract — and it does, enumerating per-tray and per-unit fields, the ``feeding``/``feeding_source`` pair, and sentinel values. An agent can call this correctly and interpret the result without further discovery.

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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The description spends its words on return-shape semantics instead, which is the right allocation for a no-arg tool.

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?

Opens with a specific verb+resource+scope: "Full AMS hardware dump — all trays, humidity, RFID (Bambu Lab only)." It immediately distinguishes itself from the two nearest siblings by name (``get_active_material`` for the active material, ``get_material`` for Kiln's software tracker).

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?

Gives explicit routing rules for both alternatives, then states concrete use cases ("check filament levels before printing, verify the correct material is loaded, or select the right ``ams_mapping`` for ``start_print()``") and redirects fault-following to ``printer_status(detail="lite")``. When-to-use, when-not-to-use and alternatives are all present.

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