Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

set_machine_repair

Destructive

Mark a 3D printer as needing repair or repaired so Kiln stops routing jobs to it while out of service and resets its condition after repair.

Instructions

Tell Kiln a printer needs repair, or that you have repaired it.

        Kiln judges a printer by its own prints.  Mark it ``needed`` when
        you are taking it out of service: routing stops choosing it, and
        a print you start on it yourself still runs, with a warning.
        Mark it ``done`` once it is fixed: from that moment it is judged
        by what it prints next, and its earlier prints stop counting
        against it.  Nothing is deleted, and the record stays yours.

        Signed in, a mark follows the printer to your Kiln account and
        to your other computers, and marks made elsewhere (another
        computer, the web) come back here.  When your account cannot
        tell whether a printer marked from another computer is this
        one, the reply carries a ``questions`` list; answer one with
        ``same_as`` (it is this printer) or ``different_from`` (it is
        not), passing the question's id and no status.

        Args:
            machine_name: The printer, by its name here.
            status: ``needed`` (out of service until repaired), ``done``
                (repaired; ``kind`` required), or ``clear`` (take back
                the latest mark).  Left out only to answer a question.
            kind: What was repaired: nozzle, hotend, extruder, bed,
                belts, or other.  Required for ``done``; optional for
                ``needed``.
            note: What you did, in your own words (optional; kept on
                this computer, never sent to your account).
            when: When it happened, ISO 8601 (``2026-10-20T14:00``).
                Left out, now.  A repair may be dated up to 30 days
                back; never ahead.
            same_as: The id of a question from an earlier reply: this
                printer IS the one marked from the other computer.
            different_from: The id of a question: it is NOT (also undoes
                a wrong yes; never asked again for that pair).

        Returns ``recorded``, the printer, ``status``, ``kind``,
        ``marked_at``, the printer's ``condition`` now, ``next`` (one
        sentence), for ``done`` a ``reset`` block saying how many
        earlier prints no longer count, and, signed in, ``account``
        (whether the mark reached it) and any ``questions``.  Refuses,
        by name, a printer Kiln cannot tell apart from another, a time
        ahead or too far back, and the hosted server, where the record
        is not kept.

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": {
      "machine_name": "<machine_name>"
    },
    "name": "set_machine_repair"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoWhat was repaired: nozzle, hotend, extruder, bed, belts, or other. Required for ``done``; optional for ``needed``.
noteNoWhat you did, in your own words (optional; kept on this computer, never sent to your account).
whenNoWhen it happened, ISO 8601 (``2026-10-20T14:00``). Left out, now. A repair may be dated up to 30 days back; never ahead.
statusNo``needed`` (out of service until repaired), ``done`` (repaired; ``kind`` required), or ``clear`` (take back the latest mark). Left out only to answer a question. Default: "".
same_asNoThe id of a question from an earlier reply: this printer IS the one marked from the other computer. Default: "".
machine_nameYesThe printer, by its name here.
different_fromNoThe id of a question: it is NOT (also undoes a wrong yes; never asked again for that pair). Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.1

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations by spelling out consequences: routing stops choosing a printer marked 'needed' but your own prints still run with a warning; 'done' resets which earlier prints count; 'clear' undoes the latest mark. It also discloses the account-sync round trip, the 'questions' list and how to answer it, what refusals look like, and that notes never leave the machine. Annotations (destructive=true) only signal mutation, so this adds real decision-relevant context.

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 purpose, then structured into behavior, Args, and Returns sections that read cleanly. However, the Args block largely duplicates schema descriptions, which is wasted text at 100% coverage; the prose sections are the parts that earn their place.

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?

With no output schema, the description carries the return contract itself, naming 'recorded', 'status', 'kind', 'marked_at', 'condition', 'next', the 'reset' block, and account/questions. Failure modes (ambiguous printer, out-of-range date, hosted server) are enumerated, so an agent knows both what it gets back and how it can fail.

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 in the description is essentially a verbatim copy of the schema's property descriptions, so little is added. The only marginal gain is the cross-parameter relationship (kind required for 'done', status omitted only when answering a question), which is already in the schema text.

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?

Opens with a specific verb and resource: 'Tell Kiln a printer needs repair, or that you have repaired it,' and the three status modes (needed/done/clear) make the operation unambiguous. It does not name any sibling (e.g. maintenance_due, report_issue, answer_printer_question) as an alternative, so an agent must infer routing from the name alone.

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?

Gives concrete when-to-use guidance per mode: mark 'needed' when taking the printer out of service, 'done' once fixed, 'clear' to take back the latest mark, and 'Left out only to answer a question' for the question-answering path. Constraints on timing (up to 30 days back, never ahead) and the hosted-server refusal are stated. It stops short of naming sibling tools an agent might confuse this with, notably answer_printer_question for the questions flow.

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