Skip to main content
Glama

cancel_print

Cancel the active 3D print job and optionally keep the nozzle and bed hot for a quick file swap or mid-print update, preventing warping and adhesion loss.

Instructions

Cancel the currently running print job.

Sends cancel via MQTT (Bambu) or REST API (OctoPrint/Moonraker)
automatically.

The printer must have an active job (printing or paused).

:param printer_name: Which printer to stop.  Omit to stop the default
    printer, which is what this did before it could be aimed.  Owning
    more than one printer is free at every tier (only running them at
    the same time is a fleet feature), so the second machine is a
    supported setup on a free licence — and control of a hot machine
    is never something a licence takes away.
:param preserve_temperatures: When ``True``, re-asserts the pre-cancel
    hotend + bed (+ chamber, if expected_chamber_target is provided)
    targets immediately after the cancel command, so the printer
    does NOT cool down.  Use this when you plan to swap in a
    different file (e.g., a mid-print decoration resume 3MF) and need
    bed adhesion + nozzle temperature held across the cancel-then-
    start-print transition.  Without this, Bambu firmware defaults
    to cooling on cancel, which can warp the existing part or kill
    bed adhesion on a partial print you're about to resume.
    Default ``False`` preserves legacy behaviour (cool down to idle).

:param expected_tool_target: Optional caller-supplied tool target to
    preserve.  When provided AND ``preserve_temperatures=True``,
    this overrides the introspected ``state.tool_temp_target``.
    Useful when the printer was paused and the firmware has already
    cleared the target (so a fresh state read returns 0) but the
    caller knows what the pre-pause target was.
:param expected_bed_target: Same as above, for the bed.  This is
    the primary fix for Bambu A1 long-pause-then-cancel: the bed
    target sometimes reads back as 0 from MQTT cache after a long
    pause, and without an explicit override the cancel preservation
    skips the bed restore.
:param expected_chamber_target: Optional chamber target (M141) to
    re-assert via raw G-code.  Not all printers expose chamber
    heating via the adapter API, so this is sent as a raw M141
    command best-effort.  Pass ``None`` to skip chamber preservation.

WARNING: Cancellation is irreversible -- the print cannot be resumed
from where it left off UNLESS a resume-mode 3MF has been pre-staged
(see ``decorate_during_print`` and ``revert_mid_print``).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
printer_nameNo
expected_bed_targetNo
expected_tool_targetNo
preserve_temperaturesNo
expected_chamber_targetNo
Install Server

TDQS

A3.5/5.0
Behavior4/5

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

The description discloses key side effects: it sends cancel via MQTT/REST, optionally preserves temperatures, and warns that without preserve_temperatures the printer cools down, potentially warping the part. It also clearly states that cancellation is irreversible unless a pre-staged resume-mode 3MF exists. These behaviors are explained, though the repetitive phrasing adds noise.

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

Conciseness2/5

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

The description is extremely verbose and contains duplicated, nonsensical phrases (e.g., 'which is what this did before it could be aimed' and 'Owning more than one printer is free...'). It repeats the same warnings and parameter explanations multiple times, making it far longer than necessary. The structure is unclear due to this redundancy.

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

Completeness3/5

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

The description provides substantial context about temperature preservation, firmware behavior, and irreversible cancellation, suggesting completeness. However, the garbled text and repetition make it difficult to parse, and some context (e.g., exact error conditions) is missing. It covers the main points but not in a clean, coherent manner.

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?

The description explains each parameter beyond the schema: printer_name (which printer), preserve_temperatures (whether to keep temperatures), and expected_bed/tool/chamber targets (overrides for temperature preservation when firmware might clear them). This adds meaning to the schema, though the wording is convoluted and repetitive.

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 clearly states the tool's function: 'Cancel the currently running print job.' This is specific and distinguishes it from sibling tools like pause_print or emergency_stop. However, the rest of the description contains verbose and garbled text (e.g., 'which is what this did before it could be aimed') that slightly obscures the clarity.

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?

The description mentions a precondition ('The printer must have an active job') and notes that cancellation is irreversible unless a resume-mode 3MF is pre-staged. It also explains temperature behavior with preserve_temperatures. However, it does not explicitly compare with alternatives like pause_print or emergency_stop, so guidance on when to choose this tool over others is limited.

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

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