Skip to main content
Glama
codeofaxel

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

select_printer_variant

Declare your printer's curated hardware variant to set an accurate temperature ceiling from verified manufacturer data, without manually entering a limit.

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.

Input Schema

NameRequiredDescriptionDefault
variant_idNoDefault: "".
printer_modelYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.0
    • removedInput schema / properties / variant_id / default
      Removed value: -""
    • addedInput schema / properties / variant_id / description
      Added value: +"Default: \"\"."
  2. Addedv1.3.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well. It discloses key behavior beyond the schema: no temperature argument is accepted, limits are curated and enforced by Kiln, the declaration is local-only, never uploaded or pooled, and is ignored on hosted multi-tenant deployments. It also warns that Kiln cannot remotely verify hardware.

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 description is front-loaded with the core purpose and is organized into paragraphs covering rationale, prerequisites, privacy, and parameters. It is somewhat long, but each section adds useful context; only minor tightening would improve conciseness.

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 two-parameter declaration tool with no annotations and no output schema, the description is complete on purpose, usage, prerequisites, privacy, and parameter meaning. It does not describe error behavior if an invalid variant is supplied, which is a minor gap.

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 only 50%, but the description compensates by documenting both parameters in an Args section. It explains that `variant_id` comes from `list_printer_variants` and that an empty string reverts to the as-shipped profile, and it gives an example value for `printer_model`. It could still specify printer-model identifier format or validation constraints more explicitly.

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 opens with a specific verb and resource: 'Declare which curated hardware variant your machine actually is.' It clearly distinguishes this declaration tool from the sibling catalog lookup 'list_printer_variants' by explaining that Kiln supplies the verified limit rather than the operator typing one.

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?

It gives explicit usage context: use this when an operator has a modified printer and wants an accurate ceiling without supplying a temperature. It states a concrete prerequisite ('Check `requires` on the variant first') and explains that selecting the variant asserts both the hardware part and any required firmware change. It also covers the revert case by saying to pass an empty string to return to the as-shipped profile.

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