Skip to main content
Glama

force_print_oversize

Override the print impossibility gate for one printer, allowing physically blocked prints (exceeding build volume or nozzle temperature) to proceed with human confirmation.

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.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
printer_idNo
ttl_minutesNo
Behavior5/5

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

With no annotations, the description fully covers behavioral aspects: it explains the temporary nature (short, per-printer override that expires), the safety classification (confirm), and the human-in-the-loop requirement. It does not contradict any annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with paragraphs, bullet points, and clear sections. Every sentence adds value, and the content is front-loaded with the core action. No redundancy or fluff.

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?

Given the lack of annotations and output schema, the description is complete: it explains the tool's behavior, safety, parameters, and expected returns ('Grant confirmation, or a confirmation-required challenge'). It also references external documentation for safety details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since the input schema provides no descriptions (0% coverage), the description explains both parameters: printer_id (with example and default behavior) and ttl_minutes (with default and max), adding value beyond the schema's titles and defaults.

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 clearly states the tool's purpose: to override the pre-print impossibility gate for a single printer. It explains the specific verb 'override' and the resource 'pre-print impossibility gate,' and distinguishes this tool from other print operations by highlighting it as an escape hatch for blocked prints.

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?

Provides explicit guidance on when to use the tool (e.g., when a print is blocked due to physical limits and intentional bypass is needed) and when not to (autonomous agents cannot self-approve). It also mentions alternative uses like sending to a different printer and clarifies that design/slicing steps are unaffected.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/codeofaxel/kiln'

If you have feedback or need assistance with the MCP directory API, please join our Discord server