Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

troubleshoot_printer

Read-only

Diagnose 3D printer issues by symptom or Bambu HMS error code to retrieve model-specific causes, fixes, fault readings, and load-step guidance.

Instructions

Diagnose a printer issue by searching the known failure modes database.

Describe the symptom (e.g. ``"under-extrusion"``, ``"layer shifting"``,
``"stringing"``) and get possible causes and fixes specific to your
printer model.

On Bambu Lab printers you can also pass ``hms_code`` — the HMS error code
the printer's screen or app shows (e.g. ``"0300_1A00_0002_0001"``, in any
separator or case).  The response echoes the normalized code and a link to
Bambu's HMS wiki page for it.  With Kiln Pro
the response also carries a decoded cause, fix, and severity for the code.

Two things in ``symptom`` are read as exact signals rather than as words,
and both narrow the answer sharply, so say them if you know them:

* a fault code anywhere in the text (``"1200-8007"``, ``"12008007"``);
* which step of a load/unload wizard failed (``"fails at step 5"``).

Every code the call names -- in ``hms_code`` or anywhere in ``symptom``,
so two codes read off ``printer_status`` fit in one call -- is read
through the same reader ``printer_status`` uses and returned under
``fault_readings`` (code, namespace, reading, and the fix when Kiln has
one).  When the printer's playbook carries none of the codes named, the
response says so in ``codes_without_a_playbook`` rather than answering
the codes with word matches alone.

A step number is the most useful sentence a user can offer about a load
failure: the response's ``load_step_reading`` says whether that step is
upstream of the melt zone, which rules a nozzle clog in or out before
anyone unscrews anything.

Args:
    printer_id: Printer model identifier.
    symptom: Description of the problem.  Optional when ``hms_code`` is
        given.
    hms_code: Optional Bambu HMS error code to look up.

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": {
      "printer_id": "<printer_id>"
    },
    "name": "troubleshoot_printer"
  }
}

Input Schema

NameRequiredDescriptionDefault
symptomNoDescription of the problem. Optional when ``hms_code`` is given. Default: "".
hms_codeNoOptional Bambu HMS error code to look up. Default: "".
printer_idYesPrinter model identifier.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • changedInput schema / properties / hms_code / description
      Previous value: -"Default: \"\"."New value: +"Optional Bambu HMS error code to look up. Default: \"\"."
    • addedInput schema / properties / printer_id / description
      Added value: +"Printer model identifier."
    • changedInput schema / properties / symptom / description
      Previous value: -"Default: \"\"."New value: +"Description of the problem.  Optional when ``hms_code`` is given. Default: \"\"."
  2. Changed4 schema fields changedv1.5.0
    • removedInput schema / properties / hms_code / default
      Removed value: -""
    • addedInput schema / properties / hms_code / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / symptom / default
      Removed value: -""
    • addedInput schema / properties / symptom / description
      Added value: +"Default: \"\"."
  3. Changed3 schema fields changedv1.2.0
    • addedInput schema / properties / hms_code
      Added value: +{
+  "default": "",
+  "title": "Hms Code",
+  "type": "string"
+}
    • addedInput schema / properties / symptom / default
      Added value: +""
    • changedInput schema / required
      Previous value: -[
-  "printer_id",
-  "symptom"
-]New value: +[
+  "printer_id"
+]
  4. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld=false/non-destructive; the description adds substantial context on top: which codes get routed through the same reader printer_status uses, that unmatched codes surface under codes_without_a_playbook rather than being word-matched, and that load_step_reading classifies a step as upstream of the melt zone. It also discloses tier gating (Kiln Pro adds decoded cause/fix/severity) and that an HMS wiki link is echoed back. That is behavior an agent could not infer from structured fields.

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?

Purpose and input guidance are front-loaded, which is good, but the prose is padded with editorializing ('the most useful sentence a user can offer about a load failure', 'before anyone unscrews anything'). The paragraph explaining that two codes read off printer_status fit in one call is convoluted and partly duplicates the earlier codes sentence. Tightening would lose no information.

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?

No output schema exists, so the description carries the full burden of describing returns, and it does: fault_readings with code/namespace/reading/fix, codes_without_a_playbook, load_step_reading, echo of the normalized code plus a wiki link. For a read-only lookup tool with three simple parameters, an agent has everything needed to call it and interpret the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description still adds real meaning: hms_code format examples and case/separator insensitivity, the fact that symptom is read as exact signals for fault codes and load-wizard step numbers, and that multiple codes can be passed in one call. This changes how an agent would construct the arguments, not just what they are called.

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 gives a specific verb and mechanism: diagnose a printer issue by searching the known failure modes database, with causes and fixes scoped to the printer model. That is far more than a restatement of the name. It does not name or contrast any of the crowded set of diagnostic siblings (troubleshoot_print_issue, diagnose_print_failure_live, get_print_diagnostic), so an agent must infer the boundary itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: describe a symptom for causes/fixes, and pass hms_code on Bambu Lab machines. The 'Optional when hms_code is given' note does establish that at least one of the two inputs is needed. There is no explicit when-to-use-this-vs-alternative guidance despite many sibling tools covering print failure diagnosis, health checks, and printer Q&A.

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