qidi-mcp

run_macro

Destructive

Executes a named QIDI printer macro with optional parameters, applying confirmation and G-code screening to run routines such as bed levelling or nozzle clearing.

Instructions

Run one of the printer's defined macros by name, with optional parameters. This is how you reach QIDI's own routines (e.g. M4029 bed levelling, CLEAR_NOZZLE, PRINT_START). Use list_gcode_commands to see what exists. Two-step confirmation, because a macro can do anything. The assembled command is screened exactly like run_gcode (deny-list, temperature and velocity/accel envelope); deny-listed macros are always refused here.

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": {
      "macro": "<macro>"
    },
    "name": "run_macro"
  }
}

Input Schema

Name	Required	Description	Default
`macro`	Yes
`params`	No
`confirm`	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.4/5.0

Behavior5/5

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

Annotations already flag destructiveHint and openWorldHint, but the description adds real substance beyond them: a two-step confirmation flow, screening through the same deny-list as run_gcode, temperature and velocity/accel envelope enforcement, and a hard guarantee that deny-listed macros are refused. That is exactly the behavioral context an agent needs before committing to an arbitrary-effect 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?

Five short sentences, front-loaded with purpose, then discovery, then the safety/confirmation model. No filler and no repetition; the most decision-relevant constraint (arbitrary effects, screened, refusal possible) lands before the agent commits.

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 values need no explanation, and the description covers discovery, safety screening, and refusal behavior for a high-risk open-world mutation. The only material gap is the mechanics of the confirm/confirm_token handshake, which an agent must currently infer.

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 all parameter meaning. It clarifies `macro` (a defined name, with examples) and hints that `params` are optional, but gives no format for the params object or argument passing, and "two-step confirmation" gestures at `confirm`/`confirm_token` without explaining the sequence or how the token is obtained.

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?

"Run one of the printer's defined macros by name, with optional parameters" gives a precise verb plus resource, and the concrete examples (M4029 bed levelling, CLEAR_NOZZLE, PRINT_START) pin down what counts as a macro. It also distinguishes itself from run_gcode by framing macros as pre-defined QIDI routines rather than raw command text.

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 tells the agent how to discover valid macro names ("Use list_gcode_commands to see what exists") and positions itself as the path to vendor routines. What is absent is an explicit statement of when to prefer run_gcode or a dedicated sibling like clean_nozzle or qidi_bed_level_calibrate over invoking the macro directly.

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

Deploy Server