qidi-mcp

get_capabilities

Read-onlyIdempotent

Discover live printer capabilities—heaters and limits, fans, sensors, LEDs, pins, filament sensors, axis travel, calibration, modules, and macro count—before assuming a feature exists.

Instructions

What this specific printer supports, discovered live: heaters and their real temperature limits, controllable fans, sensors, LEDs, output pins, filament sensors, axis travel, calibration features, QIDI-specific Klipper modules, Moonraker components present, and macro count. Call this before assuming a feature exists — QIDI ship a trimmed Moonraker and an extended Klipper.

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

Input Schema

Name	Required	Description	Default
`refresh`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.1Nov 9, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. "Discovered live" adds genuinely useful behavior context (results reflect actual firmware, not a static manifest), but with a refresh parameter present the description never explains caching or what re-discovery costs — a notable omission for a live-probe tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense and front-loaded: the inventory sentence comes first, the actionable "call this before assuming" guidance second. The long enumeration is slightly heavy but each item adds real discriminating content; no filler sentences.

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?

With an output schema present, the description need not detail return values, and its category list is thorough for the tool's scope. The only real gap is the undocumented refresh/caching semantics, which is minor relative to overall completeness.

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

Parameters2/5

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

Schema coverage is 0% and the single parameter (refresh, default false) is never mentioned in the description. The "discovered live" phrasing hints that results may be cached, but an agent cannot learn from the text that refresh forces re-discovery rather than returning cached capabilities.

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 (report what this printer's live-discovered capabilities are) and enumerates the concrete categories returned: heaters with real limits, fans, sensors, LEDs, pins, filament sensors, axis travel, calibration features, QIDI Klipper modules, Moonraker components, macro count. This clearly separates it from config-dump siblings like get_printer_config or get_system_info.

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?

Gives explicit when-to-use guidance: "Call this before assuming a feature exists," with the rationale that QIDI ships a trimmed Moonraker and extended Klipper. It does not name a specific alternative for narrower questions, but the trigger condition is unambiguous enough to act on.

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

Deploy Server