Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

fleet_cancel

Destructive

Cancel prints across all or selected 3D printers in your fleet. First call returns the planned actions for review; call again with the digest to run them, optionally holding pre-cancel temperatures.

Instructions

Cancel prints across the whole fleet, gracefully (Business).

This tool may ask this computer to act on your printer (upload, start, pause, resume, set a speed preset). It first answers with the actions it wants and why, and runs nothing; call it again with run_actions set to the actions_digest it answered with to carry out exactly those actions through Kiln's own tools here, with every check those tools make.

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

Input Schema

NameRequiredDescriptionDefault
run_actionsNoLeave empty on the first call: the tool answers with the actions it wants and an actions_digest, and runs nothing. Call again with that digest here to carry out exactly those actions. Default: "".
printer_namesNoWhich printers to cancel. Omit for every registered machine (each physical machine once).
preserve_temperaturesNoHold each machine's pre-cancel temperatures after the cancel (staged-swap workflows). Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • changedInput schema / properties / preserve_temperatures / description
      Previous value: -"Default: false."New value: +"Hold each machine's pre-cancel temperatures after the cancel (staged-swap workflows). Default: false."
    • addedInput schema / properties / printer_names / description
      Added value: +"Which printers to cancel.  Omit for every registered machine (each physical machine once)."
    • changedInput schema / properties / run_actions / description
      Previous value: -"Default: \"\"."New value: +"Leave empty on the first call: the tool answers with the actions it wants and an actions_digest, and runs nothing. Call again with that digest here to carry out exactly those actions. Default: \"\"."
  2. Addedv1.5.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds substantial context beyond that: the first call is a dry run returning intended actions plus an actions_digest, and nothing executes until the second call echoes that digest. It also warns that the tool may ask the local computer to act on a printer. It stops short of saying whether cancellation is irreversible or what happens to in-progress versus queued jobs.

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 purpose is front-loaded in a short first sentence with the tier marker, and the second paragraph follows with the mechanics in a logical order. Some of the run_actions explanation duplicates the schema, and the parenthetical list of printer operations is broad and only loosely tied to a cancel action.

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 three-parameter, no-output-schema destructive fleet tool, the description supplies the critical missing piece: the confirm-by-digest safety protocol that prevents accidental mass cancellation. The main remaining gap is outcome information, such as whether already-printing jobs stop immediately and what the returned actions list looks like.

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 run_actions, printer_names, and preserve_temperatures are all documented in the schema already. The description restates the run_actions digest handshake but adds no new syntax or edge-case meaning beyond what the field descriptions carry. Baseline 3 applies when the schema does the heavy lifting.

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 verb and resource with a clear scope: 'Cancel prints across the whole fleet.' An agent immediately knows this is a fleet-wide cancellation rather than a single-printer action. It does not name the near-siblings (cancel_print, fleet_pause, fleet_resume, cancel_queued_job), so differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the fleet scope and by the printer_names schema field, which allows omitting the list for all machines. However, there is no explicit statement of when to prefer this over cancel_print for one machine, or over fleet_pause for a stoppable-and-resumable action. The two-phase call protocol is described, but that is invocation mechanics rather than when-to-use guidance.

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