Skip to main content
Glama

cancel_queued_jobs

Destructive

Cancel all queued print jobs in bulk, optionally limited to one printer, and use a dry-run preview to see which jobs would be cancelled without changing anything.

Instructions

Cancel ALL queued print jobs at once.

The bulk companion to ``cancel_queued_job`` (which cancels one job by id).
Cancels every job currently in the QUEUED state — clear a backed-up
queue in one call instead of cancelling one job at a time.

- ``printer_name``: limit the sweep to one printer's queued jobs; omit
  to clear every queued job.
- ``dry_run=True``: preview exactly which jobs WOULD be cancelled and
  change nothing.  Run this first when clearing a large queue.

Safety: this never cancels a running print.  Only jobs still in the
QUEUED state are cancelled; each job's status is re-checked immediately
before cancelling, so a job that has already started printing (or
finished, or was cancelled elsewhere) is skipped rather than
interrupted.  Use ``cancel_print`` to stop the job that is actually
running.  Each cancel emits the same ``JOB_CANCELLED`` event as
``cancel_queued_job``.

Returns ``{success, dry_run, count, cancelled, skipped, message}`` —
``count`` always equals ``len(cancelled)``; ``skipped`` is a list of
``{job_id, reason}`` for jobs that were not cancelled.
:param printer_name: Limit the sweep to one printer's queued jobs; omit to
    clear every queued job.
:param dry_run: ``True`` previews exactly which jobs would be cancelled
    and changes nothing.  Run this first when clearing a large queue.

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

Input Schema

NameRequiredDescriptionDefault
dry_runNo``True`` previews exactly which jobs would be cancelled and changes nothing. Run this first when clearing a large queue. Default: false.
printer_nameNoLimit the sweep to one printer's queued jobs; omit to clear every queued job.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • changedInput schema / properties / dry_run / description
      Previous value: -"Default: false."New value: +"``True`` previews exactly which jobs would be cancelled and changes nothing.  Run this first when clearing a large queue. Default: false."
    • addedInput schema / properties / printer_name / description
      Added value: +"Limit the sweep to one printer's queued jobs; omit to clear every queued job."
  2. Changed3 schema fields changedv1.5.0
    • removedInput schema / properties / dry_run / default
      Removed value: -false
    • addedInput schema / properties / dry_run / description
      Added value: +"Default: false."
    • removedInput schema / properties / printer_name / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the destructive annotation, it explains that only QUEUED jobs are cancelled, status is re-checked immediately before cancelling, running/finished jobs are skipped rather than interrupted, and JOB_CANCELLED events are emitted. It also documents the return shape, which is valuable because no output schema exists.

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 definition is front-loaded with the action and then uses bullets for parameters and a safety paragraph. It is somewhat repetitive with the schema and includes a duplicated :param section, but the extra detail is mostly useful.

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 destructive bulk cancellation tool with no output schema, the description covers timing, safety, filtering, preview mode, return fields, and sibling alternatives. An agent has enough information to invoke it correctly and safely.

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 both parameters are already documented. The description reinforces the effect of printer_name omission and dry_run preview behavior, but adds little parameter meaning beyond what the schema already provides.

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 opens with a specific verb and scope: cancel ALL queued print jobs at once. It explicitly distinguishes this bulk operation from cancel_queued_job and cancel_print, so an agent can select the correct tool without opening the schema.

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?

It states exactly when to use this bulk companion, explains printer_name filtering, recommends dry_run for large queues, and points to cancel_print for running jobs. The alternatives and exclusions are explicit.

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