Skip to main content
Glama

repair_guide

Read-only

Walk through a printer maker's own repair guide one step per call, serving the maker's power-off warning, numbered steps, images and checks in their published order.

Instructions

Walk through the printer maker's own repair guide, one step per call.

The guide is the maker's published page for THIS model, reproduced in the
maker's order: their power-off warning first, their numbered steps in
their words, their picture for each step (as a URL, served from their
site with attribution -- Kiln never copies it), and their own check at
the end where the page has one.  Kiln adds words only where the picture
cannot say it.  Where the maker states them, the header carries the
tools, the interval ("every 10-15 spools") and the parts.

**Run it in steps, with the person at the machine.**  ``plan_only=True``
returns the header (maker, page title and URL, the maker's own "also
applies to" sentence, tools, interval, parts) plus step 0 and the step
titles.  ``step=0`` is ALWAYS the maker's power-off warning, verbatim.
``step=N`` returns only step N and names step N+1.  Every step from 1 on
requires ``power_off_confirmed=True`` -- a PERSON's statement that the
printer is off and unplugged; without it the call is refused with
``POWER_OFF_REQUIRED`` and the warning itself.  Never set it on a
person's behalf.  A person who is already partway in (the screw is out)
skips ahead with ``step``; Kiln never assumes where they are.  The last
step of a guide that fixes or replaces a part carries
``record_the_repair``: once the person says it is done, ask whether to
mark the printer repaired (``set_machine_repair``), so Kiln judges it by
its next prints.

Where Kiln has no guide for the topic it says so: the maker's own
maintenance index for this model where Kiln knows it (``maker_index_url``),
otherwise "your maker publishes no guide Kiln can step through".  No
generic procedure is ever presented as the maker's.

Args:
    printer_id: Printer model identifier (e.g. ``bambu_a1_mini``).  Omit
        to use the declared ``printer_model`` of ``printer_name`` (or the
        default printer).
    topic: What to repair -- ``cutter``, ``nozzle``, ``hotend``,
        ``ptfe_tube``, ``extruder_gears``, ``belts``, ``bed_level``,
        ``lubrication``, ``firmware_recovery``, ``filament_sensor``.  A
        fault code written here is read as one.
    hms_code: The code on the printer's screen (``"1200-8001"``, any
        separators); where it maps to a guide, that guide is chosen and
        the answer says which step to start at.
    step: Which step to serve (0 = the power-off warning).  Ignored with
        ``plan_only``.
    plan_only: Return the header and step titles; serve no step.
    power_off_confirmed: A PERSON has powered the printer off and
        unplugged it.  Required for every ``step >= 1``.
    printer_name: Which registered printer's declared model to use when
        ``printer_id`` is omitted.
    guide: A guide's slug, from a ``choices`` answer.  When a topic
        matches more than one of the maker's guides for this model (one
        Kiln printer id can cover two machines; a maker often has two
        pages for one job) the answer lists them and nothing is picked
        for the person -- ask, then pass the chosen slug here.

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

Input Schema

NameRequiredDescriptionDefault
stepNoWhich step to serve (0 = the power-off warning). Ignored with ``plan_only``. Default: 0.
guideNoA guide's slug, from a ``choices`` answer. When a topic matches more than one of the maker's guides for this model (one Kiln printer id can cover two machines; a maker often has two pages for one job) the answer lists them and nothing is picked for the person -- ask, then pass the chosen slug here. Default: "".
topicNoWhat to repair -- ``cutter``, ``nozzle``, ``hotend``, ``ptfe_tube``, ``extruder_gears``, ``belts``, ``bed_level``, ``lubrication``, ``firmware_recovery``, ``filament_sensor``. A fault code written here is read as one. Default: "".
hms_codeNoThe code on the printer's screen (``"1200-8001"``, any separators); where it maps to a guide, that guide is chosen and the answer says which step to start at. Default: "".
plan_onlyNoReturn the header and step titles; serve no step. Default: false.
printer_idNoPrinter model identifier (e.g. ``bambu_a1_mini``). Omit to use the declared ``printer_model`` of ``printer_name`` (or the default printer). Default: "".
printer_nameNoWhich registered printer's declared model to use when ``printer_id`` is omitted. Default: "".
power_off_confirmedNoA PERSON has powered the printer off and unplugged it. Required for every ``step >= 1``. Default: false.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.5.1
    • changedInput schema / properties / guide / description
      Previous value: -"Default: \"\"."New value: +"A guide's slug, from a ``choices`` answer.  When a topic matches more than one of the maker's guides for this model (one Kiln printer id can cover two machines; a maker often has two pages for one job) the answer lists them and nothing is picked for the person -- ask, then pass the chosen slug here. Default: \"\"."
    • changedInput schema / properties / hms_code / description
      Previous value: -"Default: \"\"."New value: +"The code on the printer's screen (``\"1200-8001\"``, any separators); where it maps to a guide, that guide is chosen and the answer says which step to start at. Default: \"\"."
    • changedInput schema / properties / plan_only / description
      Previous value: -"Default: false."New value: +"Return the header and step titles; serve no step. Default: false."
    • changedInput schema / properties / power_off_confirmed / description
      Previous value: -"Default: false."New value: +"A PERSON has powered the printer off and unplugged it.  Required for every ``step >= 1``. Default: false."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Printer model identifier (e.g. ``bambu_a1_mini``).  Omit to use the declared ``printer_model`` of ``printer_name`` (or the default printer). Default: \"\"."
    • changedInput schema / properties / printer_name / description
      Previous value: -"Default: \"\"."New value: +"Which registered printer's declared model to use when ``printer_id`` is omitted. Default: \"\"."
    • changedInput schema / properties / step / description
      Previous value: -"Default: 0."New value: +"Which step to serve (0 = the power-off warning).  Ignored with ``plan_only``. Default: 0."
    • changedInput schema / properties / topic / description
      Previous value: -"Default: \"\"."New value: +"What to repair -- ``cutter``, ``nozzle``, ``hotend``, ``ptfe_tube``, ``extruder_gears``, ``belts``, ``bed_level``, ``lubrication``, ``firmware_recovery``, ``filament_sensor``.  A fault code written here is read as one. Default: \"\"."
  2. Addedv1.5.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare it a safe read; the description adds far more: step 0 is always the maker's power-off warning verbatim, every step >= 1 is refused with POWER_OFF_REQUIRED unless power_off_confirmed is a person's own statement, Kiln never assumes the person's position, images are attributed URLs never copied, and Kiln adds words only where the picture cannot say it. These are real behavioral constraints an agent must respect when calling, not restatements of readOnlyHint.

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?

The prose is front-loaded: purpose, then the step mechanics and safety gate, then failure/no-guide behavior, then args. Bold emphasis on the run-in-steps rule and the POWER_OFF_REQUIRED refusal helps scanning. It is long and the Args section repeats much of what the body already said, which costs a point.

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, multi-turn tool with an output schema, this covers everything an agent needs: what plan_only and step return, the required safety confirmation and its refusal code, the mid-repair skip-ahead path, the ambiguity/ch 'choices' resolution flow, and the no-guide fallback. Return-value explanation is rightly left to the output schema.

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 Args block largely mirrors the schema text, so most parameter meaning is already structured. It does add real semantics in the body (the guide slug comes from a choices answer and must be asked of the person; omitted printer_id falls back to printer_name's declared model), but that guidance is duplicated in the schema descriptions rather than being new information.

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 gives a specific verb and resource ('Walk through the printer maker's own repair guide, one step per call') and pins the scope to the maker's own published page for THIS model, which separates it from generic diagnostic siblings like troubleshoot_printer or answer_printer_question. It explicitly refuses to present a generic procedure as the maker's, so an agent cannot mistake its output for generic advice.

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?

Strong workflow routing: plan_only for the header and titles, step=N to serve one step, step to skip ahead for a person already mid-repair, and the handoff to set_machine_repair when the last step carries record_the_repair. It also states the no-guide case and the maker_index_url fallback. It does not name any sibling tool (e.g. troubleshoot_printer) as an alternative for topics outside repair, so it falls just short of the top band.

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