Slicewise

Overview Schema Source Related Servers Discussions Admin

Slice (after flattening the inheritance chain)

bambu_slice

Idempotent

Slices 3D models with BambuStudio CLI; flattens presets to avoid default fallback, then reports layer count, print time, filament weight, and override audit results.

Instructions

Slices with the BambuStudio CLI and reports real statistics: layer count, print time, filament weight. Presets are flattened before they are passed to the CLI; feeding the raw presets to the CLI makes every inherited parameter fall back to the built-in default (BambuStudio#1704), so do not call the CLI directly. After slicing, it reads the settings that actually took effect back from the output and audits each override you requested; an overrideAudit entry with honoured = false was not applied. Starts a child process and writes a .gcode.3mf to the configured output directory. It does not send anything to a printer or start a print.

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_slice"
  }
}

Input Schema

Name	Required	Description
`plate`	No
`modelPath`	Yes	Absolute path to the model file; it must be inside an allowed model directory.
`overrides`	No	Parameters to override; each key is a BambuStudio setting name (e.g. layer_height, sparse_infill_density).
`placement`	No
`machinePreset`	No
`processPreset`	No
`reportSettings`	No	Read back the values these parameters actually took in the output. Use it to confirm the slice really used the preset values rather than the slicer's built-in defaults.
`filamentPresets`	No

Output Schema

Name	Required	Description
`ok`	Yes
`stats`	No
`reason`	No
`warnings`	No
`outputPath`	No
`stderrTail`	No
`overrideAudit`	No
`appliedSettings`	No	The actual values in the output of the parameters requested by reportSettings.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Adds substantial behavior beyond the annotations: it flattens presets, spawns a child process, writes a .gcode.3mf to the configured output directory, and audits overrides with an overrideAudit honoured=false signal. The annotations already declare non-readOnly, non-destructive, idempotent, closed-world; the description is consistent with them but does not address where output lands on failure or how long slicing takes, so it falls short of 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?

Front-loads what the tool does and its key outputs, then adds the critical preset-flattening warning and the scope exclusion. Dense but every clause carries information; slightly run-on with several ideas packed into single sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the description covers the mutation/output side effects well. But for an 8-parameter tool with nested placement options at low schema coverage, the description leaves too many inputs unexplained for an agent to call it confidently.

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 only 38% across 8 parameters, and the description only adds meaning for reportSettings (read-back confirmation) and overrides (audited). plate, machinePreset, processPreset, filamentPresets, and the whole placement object are left to the schema with no added semantics.

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 ("Slices with the BambuStudio CLI") plus the concrete outputs (layer count, print time, filament weight), and explicitly bounds the action ("does not send anything to a printer or start a print"), which separates it from the inspection/planning siblings.

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 strong directive not to call the CLI directly, explains why (BambuStudio#1704 inherited-parameter fallback), and excludes printing. However, it never routes the agent to sibling tools such as bambu_check_printability or bambu_plan_settings as prerequisites, so the when-to-use-vs-alternatives guidance is clear but incomplete.

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

Deploy Server