Wandy3D

Check a model for 3D printing

check_print

Idempotent

Will this model 3D-print? Free check of one of the user's models at a chosen size: verdict (ready / review / fix) with reasons, printed size, material and print time, supports, and the repairs made to get one closed printable solid. The print-ready file (3MF / STL) comes along with a Wandy3D plan, an unlocked model or an API-made model; otherwise the answer names its one-time price in credits — only after the user's yes call again with pay_credits: true. Takes 30 s – 2 min; may return a task_id for get_task.

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": {
      "model_id": "<model_id>"
    },
    "name": "check_print"
  }
}

Input Schema

Name	Required	Description	Default
`format`	No	File format of the print file (default 3mf)	3mf
`process`	No	fdm = filament printer (default; minimum wall 1.2 mm) or resin (minimum wall 0.6 mm)	fdm
`model_id`	Yes	model_id of one of the user's models (list_models / get_task)
`length_mm`	No	Printed size of the model's longest side in millimetres (30–400, default 150)
`pay_credits`	No	true = buy the print-ready file with the user's credits at the price the previous answer named. Only after the user agreed.
`wait_seconds`	No	How long to wait for the result before answering with a task_id (0–50 s, default 30)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is largely covered. The description adds genuinely useful behavior beyond them — the 30 s to 2 min runtime, the possible task_id return for get_task, and the fact that a one-time credit price may apply only after the user consents. It stops short of describing what happens on failure or whether repeated calls consume credits.

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?

Every clause earns its place: verdict semantics, output artifacts, pricing gate, latency, and async fallback, all front-loaded after the leading question. The single dense sentence with colons and dashes is compact rather than padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of describing returns, and it does so thoroughly: verdict with reasons, printed size, material, print time, supports, repairs made, and the delivered 3MF/STL file. Combined with the pricing and timing notes, an agent has everything needed to call it and interpret the result.

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?

Schema coverage is already 100%, so the baseline would be 3. The description goes further by explaining the pay_credits workflow ('only after the user's yes call again with pay_credits: true' at the price a previous answer named) and by implying the wait_seconds/task_id trade-off, which the schema alone does not connect.

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?

The description opens with the exact question the tool answers ('Will this model 3D-print?') and then specifies the resource (one of the user's models at a chosen size) and the verdict vocabulary (ready / review / fix). This is clearly distinguishable from generation, export, or listing siblings.

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 establishes the free-check context, the paid follow-up path gated on an explicit user 'yes' with pay_credits: true, and the async escape hatch ('may return a task_id for get_task'). It does not explicitly state when to prefer a sibling such as export_model, but the usage conditions it does give are concrete.

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

All Wandy3D tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?