Slicewise

Overview Schema Source Related Servers Discussions Admin

Check printability

bambu_check_printability

Read-onlyIdempotent

Detect printability issues before slicing by checking build volume, floating bodies, mesh integrity, overhangs, base area, aspect ratio, thin features, and warping risk. Each finding lists parameters.

Instructions

Finds problems visible before slicing: exceeding the build volume, floating bodies that do not touch the plate, an unclosed mesh, the share of steep overhangs, too small a base area, too high an aspect ratio, features that are too thin, and warping risk on large bottom surfaces. Each finding lists the related parameters. Floating detection splits the mesh into shells, merges shells that touch or intersect into bodies, merges shells fully enclosed by another body into it, then checks whether each body reaches the plate and measures the gap to the nearest body: a narrow gap means the parts were not joined in the model (turning on support would make them print as separate pieces); only a wide gap really needs support. Accepts STL, 3MF and OBJ. This is geometric analysis, not a slicing simulation; thin walls inside the model only show up when actually sliced. 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_check_printability"
  }
}

Input Schema

Name	Required	Description
`modelPath`	Yes
`buildVolume`	No	Defaults to 256×256×256 mm (Bambu Lab P1S / X1C).
`lineWidthMm`	No
`overhangThresholdDegrees`	No	Angle from vertical; 0° is a vertical wall, 90° is a horizontal ceiling. Defaults to 45.

Output Schema

Name	Required	Description
`findings`	Yes
`inspection`	Yes
`buildVolume`	Yes
`floatingBodies`	No	Bodies that do not touch the plate. A gap within 2 mm usually means the parts were not joined during modelling and must be fixed in the modelling software; turning on support would make them print as separate pieces.
`fitsBuildVolume`	Yes
`overhangAreaRatio`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the trailing 'No side effects' is redundant. The description still adds genuine behavioral context the annotations cannot: the shell/bodies floating-detection algorithm, the wide-vs-narrow gap interpretation, and the accepted file formats. It also discloses a real limitation (interior thin walls are not detected), which prevents misreading the result as validation.

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 findings list is front-loaded and scannable, and the algorithmic detail on floating detection is placed after it. The floating-detection sentence is long and carries some implementation minutiae, but it changes how the agent interprets a finding, so it earns its place.

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?

An output schema exists, so the description does not need to explain return values, yet it still notes that each finding lists the related parameters. Combined with the scope limits versus slicing, the file-format support, and the annotation-backed safety profile, an agent has everything needed to call and interpret the tool.

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 coverage is around 50%: buildVolume and overhangThresholdDegrees are documented in the schema, while modelPath and lineWidthMm are not. The description partially compensates by stating accepted formats (STL, 3MF, OBJ) for modelPath, but it never explains what lineWidthMm controls or how units work, so the gap is only partly closed.

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?

States a specific verb and resource and enumerates the exact checks it performs (build volume, floating bodies, unclosed mesh, overhangs, base area, aspect ratio, thin features, warping). It also explicitly distinguishes itself from the neighboring bambu_slice: 'This is geometric analysis, not a slicing simulation.'

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?

Implies the pre-slice use case and draws a clear boundary against slicing ('thin walls inside the model only show up when actually sliced'), giving the agent a real decision rule. It does not explicitly name alternatives such as bambu_inspect_model or bambu_measure_clearance, so routing is inferred rather than stated.

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

Deploy Server