qidi-mcp

start_print

Destructive

Starts printing a G-code file stored on the QIDI printer after a two-step token confirmation, preventing wrong-file launches and refusing new jobs while one is running.

Instructions

Start printing a G-code file already on the printer (path relative to the gcodes root, e.g. 'benchy.gcode' or 'projects/bracket.gcode'). Two-step confirmation: the first call returns the file's slicer metadata plus a token so you can check you are printing the right thing, and the second call with that token starts it. Refused if a job is already running.

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": {
      "filename": "<filename>"
    },
    "name": "start_print"
  }
}

Input Schema

Name	Required	Description	Default
`confirm`	No
`filename`	Yes
`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/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the mutation/safety profile is covered structurally. The description adds genuinely useful behavior beyond that: the mandatory two-step token handshake and what the first call returns, plus the refusal condition. It stops short of stating permission or lease requirements, which is a notable omission for a destructive operation.

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 dense clauses, front-loaded with the action and file argument, then the confirmation protocol, then the refusal condition. No filler and nothing repeated from the schema or title.

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, so return payloads need not be spelled out, and the description usefully previews the slicer metadata and token returned by the first call. The remaining gap is environmental prerequisites (lease, permissions) and the role of the 'confirm' flag for a destructive, non-idempotent action.

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 0%, so the description must carry the load. It documents 'filename' thoroughly (relative path, examples) and explains where confirm_token comes from, but the 'confirm' boolean parameter is never mentioned and its relationship to the token flow is unexplained.

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 ('start printing a G-code file already on the printer') and pins down the file reference as a path relative to the gcodes root with two concrete examples. It is unmistakably distinct from siblings like cancel_print, pause_print, or the file-management tools.

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?

Explains the two-step confirmation flow and the explicit exclusion 'refused if a job is already running', which tells the agent when this call will not succeed. It does not name a prerequisite step (e.g. ensuring the file was uploaded or a lease acquired), leaving a small inference gap.

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

Deploy Server