Skip to main content
Glama
codeofaxel

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

hand_back_printer

Release a printer from Kiln's control so it can focus on another machine while your print continues unchanged. Call without a printer name to check which printer Kiln is currently managing.

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.

        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.

Input Schema

NameRequiredDescriptionDefault
printer_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.0
    • removedInput schema / properties / printer_name / default
      Removed value: -null
  2. Addedv1.3.1

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description does substantial work: it says nothing is cancelled or paused, the print continues unchanged, and only Kiln's sense of responsibility changes. It also discloses the one-time return behavior and the report-only no-argument mode. It does not mention authorization requirements, error behavior, or return formatting, so it falls short of fully carrying the behavioral burden.

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 first sentence is front-loaded and clear, but the description is long and literary for a one-parameter tool, with several explanatory passages that could be condensed. The information is mostly useful, but the structure spends more space than necessary on repetition and framing.

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?

Given the simple one-optional-parameter schema and no output schema, the description covers the critical behavior: what changes, what does not change, how to query current state, and when to prefer the fleet tier. It is slightly incomplete because it does not describe the shape of the report returned when printer_name is omitted, nor error or permission conditions.

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 0%, so the description must explain the sole parameter, and it does: printer_name identifies the printer to hand back, and omitting it reports the current printer without changing anything. It does not specify name format or validation rules, but the semantic meaning and omit behavior are clear.

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?

The description states a specific action and resource: handing a printer back so Kiln stops driving it while the print continues. It clearly explains the below-fleet-tier single-printer model, but it does not explicitly distinguish this from nearby siblings such as release_printer_lock or acquire_printer_lock, leaving some ambiguity for an agent scanning the tool list.

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 usage conditions: use this below the fleet tier to release Kiln's attention, and avoid going back and forth between two running printers because that is what the fleet tier is for. It also explains the no-argument report-only mode. The alternative is described conceptually as 'the fleet tier' rather than by naming a specific sibling tool.

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