Skip to main content
Glama

pause_print

Destructive

Pause a running 3D print and hold key temperatures so the part stays secured and the nozzle is not left hot; resume later from the same point.

Instructions

Pause the currently running print job.

What happens next is decided partly by the printer's own firmware, and
it differs a lot between machines: some lift the nozzle and park the
head, others leave it resting on the part.  Check ``printer_status``
before saying where the head is.

While the print is paused Kiln holds the temperatures that matter:

  - The bed stays at its pre-pause target for the whole pause, so the
    part stays stuck down and can be resumed.
  - The nozzle is not left sitting hot over the part.  If the printer
    lowers it by itself (a Bambu A1 sets about 90°C at once), Kiln leaves
    that alone.  If the printer would keep it at full heat, Kiln switches
    it off 45 seconds into the pause, so a quick look costs nothing.
  - ``resume_print`` heats the nozzle back to the print's temperature and
    waits for it before the print continues, so a resume never pushes
    plastic through a cold nozzle.

A temperature the person sets during the pause is the one kept.  An
emergency stop ends the hold.  On a printer Kiln cannot set temperatures
on (Prusa Link) the printer's own pause behaviour applies.

Args:
    keep_temps: When ``True`` (default), the bed is held at its
        pre-pause target for the whole pause and the nozzle is not left
        sitting hot over the part (switched off shortly into the pause
        unless the printer lowers it itself); ``resume_print`` reheats
        it.  ``False`` leaves both heaters to the printer.
    printer_name: Which printer to pause.  Omit for the default
        printer.  Each paused machine gets its own hold.
    leave_nozzle: The person will work the filament during this pause:
        load new filament after a runout, clear a clog.  Kiln then never
        switches the nozzle off, and leaves it to them and the printer.
        The bed is still held.

Use ``resume_print()`` to continue from where the print left off — pass
the same ``printer_name`` you paused with.  The hold ends on that
printer's resume or cancel.

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

Input Schema

NameRequiredDescriptionDefault
keep_tempsNoWhen ``True`` (default), the bed is held at its pre-pause target for the whole pause and the nozzle is not left sitting hot over the part (switched off shortly into the pause unless the printer lowers it itself); ``resume_print`` reheats it. ``False`` leaves both heaters to the printer. Default: true.
leave_nozzleNoThe person will work the filament during this pause: load new filament after a runout, clear a clog. Kiln then never switches the nozzle off, and leaves it to them and the printer. The bed is still held. Default: false.
printer_nameNoWhich printer to pause. Omit for the default printer. Each paused machine gets its own hold.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • changedInput schema / properties / keep_temps / description
      Previous value: -"Default: true."New value: +"When ``True`` (default), the bed is held at its pre-pause target for the whole pause and the nozzle is not left sitting hot over the part (switched off shortly into the pause unless the printer lowers it itself); ``resume_print`` reheats it.  ``False`` leaves both heaters to the printer. Default: true."
    • addedInput schema / properties / leave_nozzle
      Added value: +{
      +  "description": "The person will work the filament during this pause: load new filament after a runout, clear a clog.  Kiln then never switches the nozzle off, and leaves it to them and the printer. The bed is still held. Default: false.",
      +  "title": "Leave Nozzle",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / printer_name / description
      Added value: +"Which printer to pause.  Omit for the default printer.  Each paused machine gets its own hold."
  2. Changed3 schema fields changedv1.5.0
    • removedInput schema / properties / keep_temps / default
      Removed value: -true
    • addedInput schema / properties / keep_temps / description
      Added value: +"Default: true."
    • removedInput schema / properties / printer_name / default
      Removed value: -null
  3. Changed1 schema field changedv1.3.1
    • addedInput schema / properties / printer_name
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Printer Name"
      +}
  4. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations declare destructiveHint=true but say nothing about what actually happens; the description fills that in with firmware-dependent head behavior, bed held at pre-pause target, nozzle cut 45 seconds in unless the printer lowers it itself, and resume reheating before extrusion. It also discloses the Prusa Link limitation and the user-temperature override rule, which are non-obvious operational constraints an agent could not infer from any structured field.

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 purpose is front-loaded and the prose is readable, but the Args section restates the schema text almost word for word, which is pure duplication, and the firmware/temperature narrative repeats itself across the body and the keep_temps description. Roughly a third of the text could be removed without losing information.

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?

There is no output schema, and the description compensates by telling the agent where to look for post-pause state (printer_status for head position) and by covering multi-printer holds and the resume/cancel termination conditions. For a three-parameter state-changing tool, nothing an agent needs in order to call it correctly is missing.

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 Args block in the description is essentially a verbatim copy of the parameter descriptions already in the schema, so little meaning is added beyond it. The one marginal addition is the interaction note that leave_nozzle still holds the bed, which the surrounding prose conveys. Baseline 3 is appropriate when the schema already documents every parameter.

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 opening sentence names a specific verb and resource ("Pause the currently running print job"), and the closing sentence distinguishes it from the sibling that continues the action ("Use resume_print() to continue from where the print left off"). An agent can separate this from resume_print, cancel_print, and emergency_stop without opening a schema.

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 context for the parameter choices (set leave_nozzle when the person will load filament or clear a clog) and names the follow-up tool and the pairing requirement ("pass the same printer_name you paused with"). It stops short of stating when not to use this tool versus emergency_stop or cancel_print, only mentioning that an emergency stop ends the hold.

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