Slicewise

Overview Schema Source Related Servers Discussions Admin

Plan settings for a goal

bambu_plan_settings

Read-onlyIdempotent

Plan Bambu Studio parameter adjustments for a goal such as safe, fast, strong, surface or economical printing, with ordered moves, costs and current preset values; optionally runs a printability analysis first.

Instructions

Given what you want (safe and failure-free / fast / strong under load / good surface / economical), returns ordered parameter adjustments grouped by what they counter: adhesion and warping, nozzle collisions, surface quality, structural strength, time, filament. Each move includes its mechanism, a suggested value, its cost, and the actual value in the current preset and its shape (per-extruder parameters must be overridden with an array; a scalar is silently not applied). If modelPath is given, a printability analysis runs first and conditional adjustments are added based on the geometry. This is for planning before a print; to work back from a print that already failed, use bambu_diagnose. It only returns a plan and changes nothing. No side effects.

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

Input Schema

Name	Required	Description
`goal`	No	What you want, in natural language, e.g. "don't let it fail, print slowly at high quality" or "in a hurry". Chinese goals are matched too.
`goalId`	No	Specify the goal directly; skips text matching.
`material`	No	PLA / PETG / ABS / ASA / TPU; a material-specific note is returned when one exists.
`modelPath`	No	If a model is given, a printability analysis runs first and conditional adjustments are added based on the geometry (e.g. a wider brim when the base area is too small).
`processPreset`	No	Defaults to the preset currently selected in Bambu Studio.
`filamentPreset`	No

Output Schema

Name	Required	Description	Default
`goal`	No
`note`	No
`moves`	Yes
`available`	Yes
`printability`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent safety, but the description adds substantially more: the plan is ordered, each move carries its mechanism, suggested value, cost, and the current preset value with its shape; per-extruder parameters require an array because a scalar is 'silently not applied.' It also discloses the conditional side path where modelPath triggers a printability analysis first, plus the explicit no-side-effects guarantee.

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-loaded with the outcome and the grouping logic before the alternative-routing sentence, and nearly every clause carries information. The long parenthetical enumerations make it dense and slightly harder to scan than a two- or three-sentence structure would be.

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?

An output schema exists, yet the description still characterizes the plan's structure well; safety is covered by annotations. The remaining gap is the unaddressed case of a call with no goal or goalId, since all six parameters are optional, leaving an agent unsure whether an empty-goal call is meaningful.

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 already 83%, so the schema carries most of the load. The description restates the modelPath behavior that the schema already documents and enumerates the goal families that the goalId enum already lists, adding little new meaning. With zero required parameters, it never addresses what happens if neither goal nor goalId is supplied.

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: given a goal, it 'returns ordered parameter adjustments grouped by what they counter' with named categories (adhesion, nozzle collisions, surface, strength, time, filament). It explicitly distinguishes itself from bambu_diagnose ('to work back from a print that already failed, use bambu_diagnose') and implicitly from the in-place optimizer by noting it 'only returns a plan and changes nothing.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use ('planning before a print') and a when-not with a named alternative ('to work back from a print that already failed, use bambu_diagnose'). It also flags the no-side-effect mode versus a sibling that presumably applies changes, so the agent can route correctly without opening other schemas.

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

Deploy Server