Fatia MCP

Overview Schema Source Related Servers Discussions Admin

compare_print_orientations

Compare up to six rotations of one selected 3MF build item, preserving paint and settings while estimating sliced print time, material, support, and bed contact for orientation choice.

Instructions

Compare up to six world-space rotations of one selected printable build item in a printer-compatible multi-plate 3MF. Preserves paint, modifiers and settings; rests each candidate on the bed and slices within explicit budgets. Returns separate unsliced projects and estimated time/material, support and geometric bed-contact evidence. No physical strength or quality guarantee; prepare STL or another printer first.

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": {
      "path": "<path>"
    },
    "name": "compare_print_orientations"
  }
}

Input Schema

Name	Required	Description
`path`	Yes	Existing compatible 3MF; select plate_index and item_index for projects with several objects.
`search`	No	orthogonal(default) or bounded deterministic256-direction surface search. Cannot combine with explicitorientations.
`item_index`	No	Global build-item index from the object list. Required when selected plate has several printable items.
`max_slices`	No	Maximum CLI attempts, including failures.
`bambu_model`	No	Selected printer model, otherwise BAMBU_MODEL or elicitation.
`max_minutes`	No	Wall-clock budget in minutes, including writing and slicing.
`plate_index`	No	Zero-based target plate; default0. Other plates remain unchanged.
`orientations`	No	World rotations applied X then Y then Z, in degrees. Defaults to the six orthogonal sides.
`allow_move_xy`	No	Explicit permission to move only the target in XY if the current center is infeasible; defaultfalse.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.47Nov 5, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden and does substantial work: it discloses that paint, modifiers and settings are preserved, that each candidate is rested on the bed and sliced under explicit time/slice budgets, and that outputs are separate unsliced projects plus estimated time, material, support and bed-contact evidence. It also sets expectations honestly ('No physical strength or quality guarantee'). It stops short of stating where the generated project files are written or what happens to the source file, which keeps it off a 5.

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?

Three sentences, front-loaded with the operation and capped with the key caveat, with essentially no filler. The middle sentence is dense and slightly run-on, packing preservation, bed-resting, slicing budgets and four classes of return evidence into one clause chain, but every element earns its place.

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 nine-parameter tool with no annotations and no output schema, the description is unusually complete: it covers what is preserved, what is computed under which budgets, and what the caller gets back, which substitutes for the missing output schema. The remaining gaps are the provenance of returned projects and the precondition failures (missing printer model, incompatible file) that an agent would want flagged before calling.

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 100%, so every one of the nine parameters (including the nested rotation axes and the search enum) is already documented, and the baseline of 3 applies. The description reinforces a few bounds ('up to six', 'explicit budgets', 'rests each candidate on the bed' as the rationale for bed-contact evidence) but adds no new syntax or interpretation beyond the schema, and never clarifies what allow_move_xy's 'infeasible center' condition means in practice.

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 and resource with explicit scope: comparing up to six world-space rotations of one selected printable build item inside a printer-compatible multi-plate 3MF. This is clearly distinct from rotate_stl (mutates) and lay_flat (single orientation), though it never names the nearest sibling, compare_slice_scenarios, so an agent must infer that boundary itself.

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

Usage Guidelines3/5

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

Usage is implied through the closing clause 'prepare STL or another printer first', which signals the tool expects an already-prepared 3MF rather than a raw mesh, and through the constraint that only one selected item/plate is evaluated. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as compare_slice_scenarios or rotate_stl, so selection between these tools is left to inference.

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