CAD to Print MCP

Overview Schema Source Related Servers Discussions Admin

run_slice

Slice a 3D model with OrcaSlicer into a unique output folder, then return the generated G-code artifacts and logs for print preparation.

Instructions

Slice with stock OrcaSlicer in a unique output folder; return artifacts and logs.

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": "<model>"
    },
    "name": "run_slice"
  }
}

Input Schema

Name	Required	Description	Default
`model`	Yes
`settings`	No
`machine_profile`	No
`process_profile`	No
`timeout_seconds`	No
`filament_profile`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

C2.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does disclose two useful traits: output goes to a unique folder (avoiding collisions) and the result is artifacts plus logs. It stays silent on runtime expectations, permission/auth needs, whether prior outputs are overwritten, and failure behavior for a tool that shells out to a slicer.

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?

A single compact sentence with the action front-loaded and the output behavior appended; nothing is padded or redundant.

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

Completeness2/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, but for a 6-parameter, annotation-free execution tool the description leaves the argument space entirely undocumented and gives no guidance on when to prefer it over preview_slice.

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

Parameters1/5

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

Schema coverage is 0% across 6 parameters, so the schema explains nothing, and the description adds no meaning for model, settings, the three profile arguments, or timeout_seconds. The only faint signal is 'stock' implying defaults, which does not compensate for the complete gap.

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?

States a specific verb ('Slice') plus the engine (stock OrcaSlicer) and its write behavior (unique output folder, returns artifacts and logs). It does not distinguish itself from the close siblings preview_slice and prepare_print_job, so an agent must still infer which slicing-stage tool to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no explicit alternative named, despite preview_slice and prepare_print_job sitting in the same family. The 'stock OrcaSlicer' phrasing only loosely implies this is the real/full slice rather than a preview.

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

Deploy Server