Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

force_print_oversize

Destructive

Grants a short, human-confirmed override for one printer so the next print blocked by build-volume, hotend-temperature, nozzle-size, or bed-size limits can proceed.

Instructions

Briefly override the pre-print impossibility gate for ONE printer.

Kiln refuses a print that physically cannot succeed on the target
printer — geometry that exceeds the build volume (the nozzle would
crash) or a material whose minimum nozzle temperature exceeds the
printer's hotend ceiling (it cannot melt the filament).  Those are
hard physical limits, not warnings, so a normal print call is blocked.
It also refuses a file sliced for one nozzle size when the printer's
own setting says another is fitted, and a part too big for the bed of
the model the printer reports itself as when that differs from the
model it was set up as; this override covers both.

This is the human's "I understand — print it anyway" escape hatch, e.g.
when you are deliberately sending the file to a *different* printer than
the one connected.  It grants a short, per-printer override that lets the
NEXT otherwise-blocked print through, then expires.

Safety: classified ``confirm`` (see ``data/tool_safety.json``).  An
autonomous agent cannot self-approve it — the confirmation layer keeps a
human in the loop, exactly like ``emergency_stop``.  Designing and slicing
any size is never blocked; only the final print-to-hardware step is.

:param printer_id: Printer model to override (e.g. ``"bambu_a1"``).
    Empty resolves to the active printer.
:param ttl_minutes: Minutes the override stays active (default 5, max 60).
:returns: Grant confirmation, or a confirmation-required challenge.

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

Input Schema

NameRequiredDescriptionDefault
printer_idNoPrinter model to override (e.g. ``"bambu_a1"``). Empty resolves to the active printer. Default: "".
ttl_minutesNoMinutes the override stays active (default 5, max 60). Default: 5.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Printer model to override (e.g. ``\"bambu_a1\"``). Empty resolves to the active printer. Default: \"\"."
    • changedInput schema / properties / ttl_minutes / description
      Previous value: -"Default: 5."New value: +"Minutes the override stays active (default 5, max 60). Default: 5."
  2. Changed4 schema fields changedv1.5.0
    • removedInput schema / properties / printer_id / default
      Removed value: -""
    • addedInput schema / properties / printer_id / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / ttl_minutes / default
      Removed value: -5
    • addedInput schema / properties / ttl_minutes / description
      Added value: +"Default: 5."
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: it declares the override is short-lived, per-printer, consumed by the NEXT otherwise-blocked print, then expires, and that it is classified `confirm` so an autonomous agent cannot self-approve and a human must be in the loop. That tells the agent to expect a confirmation-required challenge rather than a silent success, which annotations alone (destructiveHint=true) would not convey.

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?

Front-loads the purpose in the first sentence and organizes the rest into blocked-case explanation, escape-hatch rationale, safety note, params, and returns. It is somewhat longer than needed for a 2-parameter tool, and the parameter block duplicates the schema, but no sentence is filler.

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

Completeness5/5

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

For a safety-critical mutation with no output schema, the description covers the trigger, the physical meaning of the gate, the expiry model, the confirm-class requirement, plus explicit return behavior ('grant confirmation, or a confirmation-required challenge'). An agent has everything needed to call it and to anticipate the human-in-the-loop handoff.

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 coverage is 100% and the description's `:param:` lines restate the schema entries (printer_id example, empty resolves to active, ttl default 5 / max 60) almost verbatim. It adds the meaningful nuance that the override is scoped per printer model, but no extra semantics for ttl interplay or what happens on re-grant. Baseline 3 fits when the schema already carries the parameter detail.

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?

States a specific verb (override) on a specific gate (the pre-print impossibility check) for a bounded scope (ONE printer), and enumerates the exact failure classes it bypasses: build-volume overrun, hotend temperature ceiling, nozzle-size mismatch, and reported-model bed mismatch. An agent can tell precisely which blocked `start_print` calls this covers, distinguishing it from slicing/design tools that are never blocked.

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?

Gives an explicit trigger scenario ('sending the file to a *different* printer than the one connected') and clarifies the boundary that designing and slicing are never blocked, only the final hardware step. It does not, however, direct the agent to remediation alternatives that appear as siblings (e.g. scale_mesh_to_fit, split_mesh_to_fit, make_printable, check_printability) before resorting to the override.

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