Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

select_printer_variant

Destructive

Declare your printer's hardware variant so Kiln applies the matching manufacturer-sourced limits without you entering temperatures. Use it to keep safety ceilings accurate for modified machines.

Instructions

Declare which curated hardware variant your machine actually is.

        This is how an operator with a modified printer gets an accurate
        ceiling WITHOUT typing one.  You say which hardware you have; Kiln
        supplies the limit from curated, manufacturer-sourced data.  There
        is no argument here that accepts a temperature, which is the point:
        a limit Kiln enforces is always a limit Kiln verified.

        Check ``requires`` on the variant first — a ceiling is only true if
        its preconditions are met.  Several variants need a firmware change
        as well as the part, and selecting the variant is your statement
        that you have done both.  Kiln cannot check your hardware remotely.

        The declaration stays on this machine.  It is never uploaded or
        pooled, and it is ignored entirely on hosted multi-tenant
        deployments, where "this machine" has no single owner.

        Args:
            printer_model: Printer identifier (e.g. ``"ender3"``).
            variant_id: Variant to declare, from ``list_printer_variants``.
                Pass ``""`` to go back to the as-shipped profile.

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_model": "<printer_model>"
    },
    "name": "select_printer_variant"
  }
}

Input Schema

NameRequiredDescriptionDefault
variant_idNoVariant to declare, from ``list_printer_variants``. Pass ``""`` to go back to the as-shipped profile. Default: "".
printer_modelYesPrinter identifier (e.g. ``"ender3"``).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / printer_model / description
      Added value: +"Printer identifier (e.g. ``\"ender3\"``)."
    • changedInput schema / properties / variant_id / description
      Previous value: -"Default: \"\"."New value: +"Variant to declare, from ``list_printer_variants``. Pass ``\"\"`` to go back to the as-shipped profile. Default: \"\"."
  2. Changed2 schema fields changedv1.5.0
    • removedInput schema / properties / variant_id / default
      Removed value: -""
    • addedInput schema / properties / variant_id / description
      Added value: +"Default: \"\"."
  3. Addedv1.3.1

TDQS

A3.7/5.0
Behavior3/5

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

The description adds substantial context beyond the annotations: the privacy guarantee ('never uploaded or pooled'), the hosted multi-tenant no-op behavior, and that Kiln cannot verify hardware so the declaration is an operator attestation. However, the annotations declare destructiveHint=true, and the description never explains what a selection overwrites or destroys (the prior variant/ceiling configuration) – a notable omission for a tool flagged as destructive.

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 is well front-loaded and the key constraints land early. But the trailing 'Args:' section duplicates the schema verbatim at 100% coverage, and the middle prose is padded with rhetorical framing ('which is the point') that costs tokens without adding information.

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

Completeness3/5

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

It covers the important non-obvious behaviors (preconditions, privacy, hosted no-op, revert) and there is no output schema to explain. Still missing for a destructive, non-readOnly mutation: what exactly changes on the machine, whether re-declaring replaces an existing variant, and what the caller gets back on success or invalid variant_id.

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%, so both parameters are already documented in structured form; the Args block largely restates them. The description does add a little meaning – that variant ids come from `list_printer_variants` and that empty string restores the as-shipped profile – but that same text is already present in the schema's `variant_id` description.

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 first sentence gives a specific verb ('Declare') and resource ('which curated hardware variant your machine actually is') and the body explicitly distinguishes this from the read-only listing sibling by naming `list_printer_variants` as the source of valid variant ids. It also clarifies the negative space – 'There is no argument here that accepts a temperature' – so an agent cannot confuse it with a set_temperature-style tool.

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 clear preconditions ('Check `requires` on the variant first') and routes the agent to `list_printer_variants` for valid ids, plus an explicit revert path (`Pass ""`). What's missing is an explicit statement of when NOT to use it (e.g. unmodified printers, or that it is ignored on hosted deployments, which is mentioned but framed as a note rather than a usage exclusion).

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