qidi-mcp

emergency_stop

DestructiveIdempotent

Immediately halts the 3D printer by cutting heaters and motion and putting Klipper into shutdown (M112) when a print looks unsafe; any active print is lost.

Instructions

EMERGENCY STOP. Immediately halts the printer: all heaters off, all motion stopped, Klipper enters a shutdown state (this is M112). Any running print is lost. Never blocked — no confirmation, and it works even in read-only mode. Use it the moment something looks wrong. Recovery afterwards needs restart_firmware.

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

Input Schema

Name	Required	Description	Default
`reason`	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.4/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and non-read-only, but the description goes well beyond them: heaters off, motion halted, firmware shutdown state, running print lost, no confirmation prompt, and usable even in read-only mode. The 'never blocked' guarantee and the explicit recovery requirement are behaviors an agent could not learn 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?

Front-loaded with the imperative and the consequence, then conditions, then recovery. Every clause carries distinct information (effects, irreversibility, unblockability, follow-up) 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, irreversible safety tool, the description covers consequences, irreversibility, confirmation behavior, and the recovery path, and an output schema exists so return values need not be explained. The only omission is any explanation of the 'reason' parameter and where it goes.

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?

There is one optional 'reason' parameter with zero schema description coverage, and the description never mentions it — no hint whether it is logged, surfaced in an audit trail, or ignored. Since only a single self-descriptive optional param is involved, the gap is modest but real.

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-plus-resource statement ('Immediately halts the printer') and enumerates the concrete effects: heaters off, motion stopped, Klipper shutdown (M112). This cleanly separates it from siblings like pause_print or cancel_print, which stop a job without shutting down the firmware.

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 a clear triggering condition ('Use it the moment something looks wrong') and names the follow-up step (restart_firmware), which is exactly the routing an agent needs. It stops short of explicitly contrasting with graceful alternatives like cancel_print or shutdown_printer, so the agent must infer that this is the last-resort path.

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

Deploy Server