Kiln

Overview Schema Source Related Servers Discussions Admin

repair_guide

Read-only

Walk through a printer maker's published repair guide one step per call, starting with the power-off warning and returning each step, image, and final check for your model.

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.

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.

Input Schema

Name	Required	Description
`step`	No	Default: 0.
`guide`	No	Default: "".
`topic`	No	Default: "".
`hms_code`	No	Default: "".
`plan_only`	No	Default: false.
`printer_id`	No	Default: "".
`printer_name`	No	Default: "".
`power_off_confirmed`	No	Default: false.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.5.0Oct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and safety, but the description adds crucial behavioral detail beyond them: refusal with POWER_OFF_REQUIRED, the 'never set it on a person's behalf' rule, verbatim maker ordering, and the no-guide fallback with maker_index_url. This is rich context an agent cannot get from annotations alone.

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 core action, then a run-in-steps block, then per-arg detail. Well-organized and nearly every sentence earns its place, though the prose is dense and could be trimmed slightly without loss.

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-param, multi-step, safety-gated tool with an output schema and populated annotations, the description covers the safety contract, refusal modes, ordering guarantees, and no-guide fallback. Nothing an agent needs to call it correctly is missing.

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 100% but the schema descriptions are bare ('Default: 0', etc.); the prose compensates heavily by explaining topic values, hms_code format and mapping behavior, step semantics, lantern for plan_only, and the multi-guide disambiguation via guide slug. Adds substantial meaning over 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?

States a specific verb+resource+scope ('Walk through the printer maker's own repair guide, one step per call') and clearly distinguishes itself from adjacent diagnostics/guide siblings. An agent immediately understands this is a stepwise maker-guide walker, not a generic troubleshoot tool.

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?

Explicit when/when-not: use plan_only for the header, step=0 is always the power-off warning, step>=1 requires power_off_confirmed, partway-in users skip ahead with step, and ambiguous topics must surface a choices list before passing guide. The workflow and its alternatives are fully spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server