Slicewise

Overview Schema Source Related Servers Discussions Admin

Measure clearance between parts

bambu_measure_clearance

Read-onlyIdempotent

Measures the smallest clearance between parts in 3MF or OBJ files to judge whether print-in-place mechanisms will fuse; touching parts are merged first.

Instructions

Measures the smallest clearance between the parts in a 3MF or OBJ, to judge whether a print-in-place mechanism will fuse when printed. Parts that touch each other are first merged into rigid bodies before comparing, because Bambu also stores the colour-change segments of a single solid as separate parts; without merging, one piece would be reported as "clearance 0". When the clearance is too small it suggests compensation, distinguishing outer contours from holes (the enclosed side is a hole to the slicer and is controlled by a different parameter). STL has no part boundaries, so it cannot be measured. No side effects.

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": {
      "modelPath": "<modelPath>"
    },
    "name": "bambu_measure_clearance"
  }
}

Input Schema

Name	Required	Description
`modelPath`	Yes	Absolute path to a 3MF or OBJ file; it must be inside an allowed model directory.
`samplingMm`	No	Surface sampling spacing; smaller is more accurate but slower. Defaults to 0.2 mm.
`reportThresholdMm`	No	Part pairs farther apart than this are left out of the report. Defaults to 2 mm.
`minimumClearanceMm`	No	The smallest clearance that prints reliably. Defaults to 0.15 (the practical lower limit for PLA with a 0.4 mm nozzle).

Output Schema

Name	Required	Description	Default
`pairs`	Yes
`bodies`	Yes
`format`	Yes
`findings`	Yes
`partCount`	Yes
`tightestGapMm`	No
`recommendation`	No
`minimumClearanceMm`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them by disclosing that touching parts are merged into rigid bodies before comparison and why (colour-change segments are stored as separate parts), which materially changes how results should be read. It further explains that compensation suggestions distinguish outer contours from holes because the enclosed side is slicer-controlled by a different parameter. 'No side effects' merely restates the annotations, but the rest is substantive behavioural context.

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 purpose is front-loaded in the first clause and the qualifiers follow in a logical order: merging caveat, compensation behaviour, format limitation, side effects. Every sentence carries real information except the closing 'No side effects', which duplicates the annotations and could be dropped.

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?

Output schema exists, so return format need not be explained here. The description covers what an agent needs to call it correctly: which formats are valid (3MF/OBJ, not STL), what preprocessing happens internally, and what the result means for printability plus the downstream compensation advice.

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 modelPath, samplingMm, reportThresholdMm and minimumClearanceMm are all documented in the schema itself. The description adds no parameter-level detail such as how lower sampling trades accuracy for speed or what units the threshold uses, so the baseline of 3 applies.

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: 'Measures the smallest clearance between the parts in a 3MF or OBJ', plus the intent (judging whether a print-in-place mechanism will fuse). That is far more precise than the title alone. It does not explicitly name near-neighbours like bambu_check_printability or bambu_optimize_print_in_place, so an agent must infer the boundary from the wording rather than from a stated rule.

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?

Gives a clear condition for use (predicting fusion of print-in-place mechanisms) and an explicit exclusion: 'STL has no part boundaries, so it cannot be measured.' It also notes the tool suggests compensation when clearance is too small. What it lacks is routing to an alternative when the answer is negative or when the file is STL – no sibling is named.

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

Deploy Server