Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

hand_back_printer

Destructive

Releases Kiln's current 3D printer so it can move on to another without cancelling or pausing the running print. Omit the printer name to only report which printer Kiln is using.

Instructions

Tell Kiln you are taking a printer from here, so it can move on.

        Below the fleet tier Kiln works with one printer at a time: the
        machine it started a print on, or one it is watching for you.
        This hands that machine back — you keep the print, Kiln stops
        being the one driving it, and its attention is free for another
        printer.

        Nothing is cancelled and nothing is paused.  The print carries on
        exactly as it was; this only changes which machine Kiln considers
        itself responsible for.

        Called with no arguments it reports which printer Kiln is working
        with, without changing anything, so you can always find out where
        its attention is before moving it.

        It moves the queue too.  Below the fleet tier the queue works on
        one printer and stays there; a queued job for another printer
        waits until the person moves Kiln to it.  When they say they are
        done with a printer, or ask for the queue to move on, hand that
        printer back: the next job in line then starts on its own printer.

        One thing worth knowing before you do it: Kiln will come back to
        this print once if you need it to, and after that it stays with
        whatever machine it moved to until this print finishes.  Going
        back and forth between two running printers is what the fleet
        tier is for.

        Args:
            printer_name: Printer to hand back.  Omit to report only.

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

Input Schema

NameRequiredDescriptionDefault
printer_nameNoPrinter to hand back. Omit to report only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / printer_name / description
      Added value: +"Printer to hand back.  Omit to report only."
  2. Changed1 schema field changedv1.5.0
    • removedInput schema / properties / printer_name / default
      Removed value: -null
  3. Addedv1.3.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say destructiveHint=true; the description goes much further by disclosing that nothing is cancelled or paused, that the print continues unchanged, that the queue travels with the handback, that Kiln returns to the print only once, and that the no-arg call is a pure report. That is exactly the kind of context annotations cannot carry.

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 lead sentence front-loads the action and the following paragraphs escalate detail sensibly. It is longer than necessary for a one-parameter tool — the 'Below the fleet tier Kiln works with one printer at a time' idea is restated across two paragraphs — but no paragraph is padding.

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?

With no output schema, the description does cover the no-argument return ('reports which printer Kiln is working with') and the state consequences of the mutating call. It does not describe what comes back after a successful handback or what happens if the named printer is not the one Kiln is working with, which are the remaining gaps.

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?

The single parameter is fully documented in the schema ('Printer to hand back. Omit to report only.'), and the description repeats that same fact rather than adding new semantics such as name formats, defaults when a printer is ambiguous, or error behaviour for unknown names. Baseline for 100% schema coverage applies.

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 names a specific verb and resource ('hands that machine back') and immediately defines the scope: the one printer Kiln is driving below the fleet tier. It also distinguishes the operation from fleet-tier behaviour, so an agent can tell what this does without reading the schema.

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-to-use triggers are given ('When they say they are done with a printer, or ask for the queue to move on'), plus an explicit when-not ('Going back and forth between two running printers is what the fleet tier is for'), plus a no-arg read-only mode for checking state first. That is a full routing decision.

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