Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

check_machine_firmware

Read-only

Check each component's firmware version on a 3D printer and identify available updates or rollbacks for supported Klipper, OctoPrint, and Creality machines.

Instructions

Check a machine's firmware: each component's version, and whether an update or a rollback is available.

        Works on Klipper (Moonraker), OctoPrint and Creality's
        Klipper-based printers.  Bambu Lab and Prusa Link printers manage
        their own firmware and answer ``UNSUPPORTED``.  Checking several
        machines in one call needs Kiln Business.

        Args:
            machine: The machine to check, by name.  Omitted, the machine
                Kiln is connected to.
            machines: Several machines to check in one call, by name.
                Each is reported on its own line.
            all_machines: Check every machine registered with Kiln.

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

Input Schema

NameRequiredDescriptionDefault
machineNoThe machine to check, by name. Omitted, the machine Kiln is connected to.
machinesNoSeveral machines to check in one call, by name. Each is reported on its own line.
all_machinesNoCheck every machine registered with Kiln. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.1

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it discloses platform coverage, an explicit non-supported outcome for specific ecosystems, and a plan-tier gate on the batch mode. Those are exactly the operational constraints an agent needs before calling, and they are not derivable from the annotations or schema.

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?

The opening sentence and platform paragraph are front-loaded and earn their place. The trailing Args block, however, duplicates the schema descriptions nearly verbatim, adding length without adding meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, three-parameter tool with no output schema, the definition covers purpose, return contents, platform support, and tier gating. The one residual gap is the interaction/precedence between the mutually overlapping machine selectors, and general failure behavior outside the UNSUPPORTED case is unstated.

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?

Schema description coverage is 100% and all three parameters are already documented in the schema, so the baseline applies. The Args block restates the schema rather than adding format or precedence detail, and notably does not clarify what happens if machine, machines, and all_machines are combined.

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 description leads with a specific verb and resource ('Check a machine's firmware') and states exactly what is returned: each component's version plus update/rollback availability. That distinguishes it cleanly from siblings like update_machine_firmware and roll_back_machine_firmware, which act on the information this tool reports.

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?

It gives concrete applicability conditions: works on Klipper/Moonraker, OctoPrint and Creality's Klipper-based printers, while Bambu Lab and Prusa Link return UNSUPPORTED, and multi-machine checking requires Kiln Business. It stops short of explicitly routing an agent to update_machine_firmware after an available update is reported, so one inference remains.

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