qidi-mcp

break_printer_lease

Destructive

Force-release another operator's stuck printer lease after confirming the holder is gone; the break is logged, and manual print claims transfer to you for control.

Instructions

Force-release SOMEBODY ELSE's lease, for when its holder has clearly gone away and the machine is stranded. Two-step confirmation, and the break is recorded in the audit log with your name. Check get_printer_lease and look at the machine first: if a print is actually running, breaking the lease does not stop it, and cancel_print or emergency_stop is what you want. On a manual-print claim (a print started at the touchscreen, shown with manual=true) this takes the print over: the claim becomes yours so you can then pause or cancel it.

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

Input Schema

Name	Required	Description	Default
`why`	No
`confirm_token`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.1Nov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the destructive/non-idempotent annotations, the description discloses that there is a two-step confirmation, that the break is attributed to your name in the audit log, that breaking does not stop a running print, and that a manual claim (manual=true) transfers ownership to you. These are material behavioral facts an agent could not infer from the annotations alone.

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?

Purpose is front-loaded in the first clause, followed by safety/audit context, then prerequisites, then the edge case of manual claims. Each sentence carries distinct actionable information with no filler.

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

Completeness4/5

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

For a destructive mutation the description covers confirmation, audit trail, side effects on running prints, and ownership transfer, and an output schema exists so return values needn't be explained. The only gap is the unexplained 'why' parameter, which is minor against otherwise thorough context.

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 0%, so the description carries the load, and it partially does: 'Two-step confirmation' implies the confirm_token parameter's role. However, the 'why' parameter is never mentioned and the token's acquisition/format is left implicit, so full compensation is missing.

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 precise verb and object — 'Force-release SOMEBODY ELSE's lease' — which immediately distinguishes it from release_printer_lease (own lease) and acquire_printer_lease. The capitalized 'SOMEBODY ELSE's' removes any ambiguity about scope.

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 the exact triggering condition ('holder has clearly gone away and the machine is stranded'), names a prerequisite check ('Check get_printer_lease and look at the machine first'), and routes to explicit alternatives ('cancel_print or emergency_stop is what you want') when a print is running. This is genuine when/when-not guidance with named siblings.

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

Deploy Server