Skip to main content
Glama

Save a user preset

save_preset
DestructiveIdempotent

Create or update a Bambu Studio user preset and back up the previous file before overwriting, so approved slicing changes can be saved for use after restart.

Instructions

Create or update a user preset in Bambu Studio's user folder. Overwrites the existing user preset of that name; the previous file is backed up in backups/ first. Only call it once the user has agreed to the changes, after slicing to compare them (compare_slices). Bambu Studio must be restarted to show the change.

Input Schema

NameRequiredDescriptionDefault
kindYesPreset type: "process" (print settings), "filament" or "machine" (printer).
nameYesName of the user preset to create or update.
parentNoPreset to inherit from when creating a new one (e.g. a system preset). Omit to update an existing user preset.
settingsYesSettings to write, as Bambu strings: {"layer_height": "0.16", "sparse_infill_density": "15%"}. Unknown setting names are rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.1
    • addedInput schema / properties / kind / description
      Added value: +"Preset type: \"process\" (print settings), \"filament\" or \"machine\" (printer)."
    • addedInput schema / properties / name / description
      Added value: +"Name of the user preset to create or update."
    • addedInput schema / properties / parent / description
      Added value: +"Preset to inherit from when creating a new one (e.g. a system preset). Omit to update an existing user preset."
    • addedInput schema / properties / settings / description
      Added value: +"Settings to write, as Bambu strings: {\"layer_height\": \"0.16\", \"sparse_infill_density\": \"15%\"}. Unknown setting names are rejected."
  2. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond annotations (destructive=true, idempotent=true), it explains that an existing preset of that name is overwritten, that the previous file is backed up in backups/ first, and that Bambu Studio must be restarted to see the change. This adds real behavioral context about destructiveness and recovery.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, each doing distinct work: purpose, overwrite/backup behavior, call precondition, and restart requirement. The important scoping and safety facts are front-loaded.

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?

For a destructive mutation tool with no output schema, the description covers what is overwritten, how the prior state is preserved, when it is safe to call, and what the user must do afterward. Annotations plus this text give the agent enough to invoke it correctly.

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 the schema already documents kind, name, parent, and settings. The description does not add parameter-level detail beyond what the schema provides, such as parent inheritance behavior or settings syntax.

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?

The description states a specific verb and resource: 'Create or update a user preset in Bambu Studio's user folder.' It is clear which operation is performed, though it does not explicitly contrast itself with sibling tools like compare_presets or get_preset.

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?

It gives an explicit precondition: 'Only call it once the user has agreed to the changes, after slicing to compare them (compare_slices).' This tells the agent both when to invoke it and which sibling tool to use first, plus a post-call restart requirement.

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