Skip to main content
Glama
danielefinocchiaro

unofficial-bambu-mcp

cut_object

Cuts a 3D object along a horizontal or angled plane, keeping both, top, or bottom pieces. Adds optional peg, dowel, or dovetail connectors so cut parts align for gluing.

Instructions

Cut an object with a plane, optionally with connectors that line the pieces up for gluing (like the connectors of Bambu Studio's Cut tool). keep: both | bottom | top. The plane is horizontal at height z (mm from the object's bottom), or goes through point [x, y, z] (plate mm, z above the bed) with normal [nx, ny, nz]: [1, 0, 0] cuts vertically across x, [0.5, 0, 1] is tilted. place: auto = the lower piece stays as it is and the upper one lies on its cut face; cut_down = both lie on their cut faces; keep = both as they were. connector: none | plug (a peg on the piece whose cut face is up, a hole with clearance mm per side in the other) | dowel (holes in both pieces and a separate pin, added to the plate) | dovetail (a tongue across the whole cut, along its length, and a slot in the other piece: they slide together from the side). shape: cylinder | square | hexagon; style: prism | frustum (tapered, centers itself); size: diameter or side in mm, or the dovetail's narrow width (0 = from the cut); depth: peg, pin or dovetail height (0 = automatic); count: 0 = one per piece of the cut (two along a long one), N = spread over the cut; positions: [[x, y], ...] or [[x, y, z]] in plate mm, taken on the plane (for a dovetail: a point on its middle line). Holes keep 2 mm of material from the edge and get shallower where a piece is thin; connectors that do not fit are listed as skipped. Modifiers, negative parts and painted colors are kept on the pieces.

Input Schema

NameRequiredDescriptionDefault
zNo
keepNoboth
sizeNo
countNo
depthNo
placeNoauto
pointNo
shapeNocylinder
styleNoprism
normalNo
objectYes
clearanceNo
connectorNonone
positionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it explains placement results, connector fitting failures, material preservation, and that modifiers, negative parts, and painted colors are kept. It does not state whether the original object is replaced/consumed, whether the cut is reversible, or what the response contains.

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 description is long but justified by a 14-parameter tool, and the main purpose and keep options are front-loaded. It is a dense run-on paragraph with many parentheticals, so structure could be improved, but there is little wasted content.

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 complex, unannotated 14-parameter mutation tool with no output schema, the description is substantially complete on cut geometry, connector behavior, and edge cases. It still lacks lifecycle details such as what objects are returned and whether the source object is modified in place.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate, and it does: it defines the cut plane via z/point/normal, explains keep, place, connector types, shape, style, size, depth, count, positions, and clearance in context. Nearly every parameter has meaningful semantics beyond its bare name.

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: 'Cut an object with a plane', with optional connectors. It clearly distinguishes the operation from generic object manipulation, but does not explicitly contrast it with the sibling split_object tool.

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?

The description explains many parameter choices and behaviors, but gives no explicit guidance on when to use cut_object versus alternatives like split_object, or when not to use it. The agent must infer tool selection from the purpose alone.

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