qidi-mcp

run_gcode

Destructive

Executes raw G-code on the printer for commands not covered by dedicated tools, screening each line with confirmations, danger gating, and range checks against the safety envelope.

Instructions

Run raw G-code on the printer — the escape hatch for anything the dedicated tools do not cover. Every line is screened: pure queries (M105, QUERY_ENDSTOPS, DUMP_TMC…) run with no confirmation, anything that acts needs confirm=true or the two-step token, and commands that bypass safety systems or rewrite config (SAVE_CONFIG, FORCE_MOVE, SET_KINEMATIC_POSITION, SET_TMC_CURRENT, PID_CALIBRATE…) are refused unless allow_dangerous=true AND the operator started the server with QIDI_ALLOW_DANGEROUS_GCODE=1. Heater targets, velocity/accel limits and coordinates are range-checked against the safety envelope. Prefer the dedicated tools — they add interlocks this cannot.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "script": "<script>"
    },
    "name": "run_gcode"
  }
}

Input Schema

Name	Required	Description	Default
`script`	Yes
`confirm`	No
`confirm_token`	No
`allow_dangerous`	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.7/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description goes well beyond them: it discloses the screening tiers (pure queries run unconfirmed, acting commands need confirm=true or a two-step token, safety-bypassing/config commands need allow_dangerous=true plus a server-side env var), range checking against a safety envelope, and that some commands are outright refused. That is exactly the interlock detail an agent needs before invoking a destructive tool.

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?

Three sentences, each doing distinct work: purpose, screening tiers, then the steering note. The escape-hatch framing is front-loaded and the policy ladder reads in increasing severity order, so it is easy to scan despite the density.

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?

An output schema exists and safety behavior is fully covered, so remaining needs are minor. What is left implicit is the failure mode — whether a refused or confirm-required command errors out, returns a token, or partially executes — which matters for a destructive tool that can run many lines per call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must carry all four parameters and it does: script is raw G-code subject to line-by-line screening and range checks, confirm is the single-step acknowledgement, confirm_token is the two-step alternative, and allow_dangerous only works when the operator set QIDI_ALLOW_DANGEROUS_GCODE=1. The escalation logic between confirm, confirm_token and allow_dangerous is otherwise unknowable from the schema alone.

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?

States a specific verb and resource ('Run raw G-code on the printer') and immediately scopes it as 'the escape hatch for anything the dedicated tools do not cover', which separates it from every dedicated operation tool in the sibling list. An agent knows exactly what class of action belongs here.

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?

Provides explicit when-to-use (anything the dedicated tools do not cover) and when-not ('Prefer the dedicated tools — they add interlocks this cannot'). The gap is that it gives no named alternative, so an agent still has to scan siblings to find the dedicated tool for a given action.

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

Deploy Server