qidi-mcp

check_print_fit

Read-onlyIdempotent

Checks whether print files match the filament type and color recorded in QIDI Box slots before printing or queueing, and reports which slots can serve each file.

Instructions

Before printing or queueing: does what the QIDI Box records in its slots suit these files? Compares each file's filament type and colours (from its slicer metadata) with the material and colour recorded per slot, and says which slots could serve each one. Names may be loose ('benchy'); an ambiguous or unknown name is an error that lists candidates. Advisory only: it never blocks, and it does not claim to know which slot the printer feeds for which tool. Returns nothing to compare on a printer with no Box.

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": {
      "filenames": "<filenames>"
    },
    "name": "check_print_fit"
  }
}

Input Schema

Name	Required	Description	Default
`filenames`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.1Nov 9, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond readOnlyHint and idempotentHint, it discloses that results are advisory and never block, that it does not claim to know which slot feeds which tool, that ambiguous or unknown names raise an error listing candidates, and that a printer without a Box returns nothing to compare. These are exactly the behavioral caveats an agent needs.

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?

Opens with the decision point ("Before printing or queueing"), then the comparison, then the edge cases. Four dense sentences with no restatement of the tool name and 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 one-parameter read-only check with an output schema, the description covers purpose, trigger, ambiguity handling, and the no-Box case. Minor omissions remain around file path semantics and what happens when a file lacks filament metadata.

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

Parameters4/5

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

The schema covers 0% of the single parameter, so the description carries the burden and mostly does: it explains that names may be loose ('benchy') and that ambiguous or unknown names produce an error with candidate slots. It does not clarify whether entries are bare names, paths, or relative to a file root.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it compares each file's filament type and colours from slicer metadata against the material and colour recorded per QIDI Box slot and reports which slots could serve each file. That is clearly distinct from siblings like get_box_status or load_box_slot, though it never names an alternative explicitly.

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?

"Before printing or queueing" gives a concrete trigger point, and the advisory framing ("never blocks") tells the agent this is a pre-flight sanity check, not a gate. It stops short of naming the sibling it complements or stating when not to bother calling it.

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

Deploy Server