Skip to main content
Glama
orcaslicer-mcp

orcaslicer-mcp

Describe plate placement from G-code

describe_plate
Read-only

Report per-object orientation, bed contact, overhangs, supports and seam positions from a finished slice's G-code, so placement and orientation questions are answered with facts.

Instructions

Describe from the G-code how each sliced part stands, touches the bed, overhangs, is supported and where its seams are; needs a finished slice.

Machine-readable facts per object, so you can answer orientation and placement questions instead of guessing from Euler angles or a picture: how the part stands (flat / tilted / on an edge or corner, from first-layer contact versus its widest layer), the first-layer footprint as islands, where overhang extrusions concentrate by 10 mm height band, where support stands and where its interface touches the part, and which side the outer-wall seams sit on (checked against seam_position). Each object gets a server-written summary sentence; relay it rather than recomputing. Read-only. Needs a valid slice; returns {"error": "not_sliced"} otherwise. Copies of one object are aggregated (Orca labels every copy 0); footprint islands still show per-copy contact. The parsed result is cached per slice (the G-code itself is still downloaded each call to detect a new slice). All bboxes are [x0, y0, x1, y1] in plate millimetres.

settings_check says whether the G-code was sliced with the settings that are set now (layer height, walls, infill, temperatures, speeds, supports, bed type, print sequence, spiral vase and every setting with an unsaved edit); any differ entry names what the slice used instead. Tell the user before printing when it lists differences.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.10

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint=true, the description discloses the failure mode ('not_sliced'), the caching model (parsed result cached per slice, G-code still downloaded each call to detect a new slice), the Orca copy-labelling quirk and how copies are aggregated while footprint islands stay per-copy, and the bbox coordinate convention in plate millimetres. It also tells the agent to relay the server-written summary sentence rather than recompute it — behaviour no annotation could convey.

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?

The lead sentence states purpose and prerequisite up front, followed by output detail and then caveats, which is a sensible ordering. The second paragraph is a dense block covering several distinct topics (aggregation, caching, bbox units, settings_check) that could be split or trimmed, but each item carries operational value rather than filler.

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 return contract itself and does so thoroughly: named facts per object, a server-generated summary, bbox units, the settings_check sub-result and its 'differ' entries. Combined with the error path and caching note, an agent has enough to call it correctly and interpret the response without further documentation.

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 input schema has zero parameters, so there is nothing for the description to disambiguate at the parameter level; the baseline of 4 applies. The description instead spends its semantic budget on the return payload (bbox format, height bands, per-copy islands), which is useful but not a parameter concern.

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 first sentence names a specific verb and resource (describe how each sliced part stands, contacts the bed, overhangs, is supported, where seams sit) and enumerates the exact facts returned. The clause about answering orientation questions 'instead of guessing from Euler angles or a picture' implicitly separates it from visual/placement tools in the sibling set, so an agent can pick it without opening another schema.

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?

Prerequisites are explicit and repeated: 'needs a finished slice' and 'Needs a valid slice; returns {"error": "not_sliced"} otherwise.' It also gives a consumption rule ('relay it rather than recomputing') and instructs the agent to surface settings_check differences before printing. It stops short of naming when a competing tool (e.g. a placement-check or diagnostic sibling) should be preferred instead, so it is context-rich but not a full decision rule.

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