bambu-printer-mcp

Overview Schema Source Related Servers Discussions Admin

print_collar_charm

Destructive

Prints a prepared two-part dog collar charm on a Bambu Lab printer, assigning the smaller inner part to black AMS slot 1 and the larger outer part to white AMS slot 2.

Instructions

Print a prepared two-part dog collar charm project using the fixed tray policy: inner/smaller object -> black on AMS 1 slot 1, outer/larger object -> white on AMS 2 slot 1.

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": {
      "bambu_model": "<bambu_model>"
    },
    "name": "print_collar_charm"
  }
}

Input Schema

Name	Required	Description
`host`	No	Hostname or IP of the printer (default: value from env)
`bed_type`	No	Bed plate type currently installed (default: textured_plate)
`timelapse`	No	Enable timelapse recording (default: false)
`bambu_model`	Yes	REQUIRED: Bambu Lab printer model. H2D, H2S, and H2C are the primary intended paths. X2D direct printing is not supported.
`bambu_token`	No	Access token (default: value from env)
`source_path`	No	Path to a prepared collar charm .3mf project or sliced 3MF. Required unless template_name is provided.
`bambu_serial`	No	Serial number (default: value from env)
`bed_leveling`	No	Auto bed leveling on or off. Omit to send what Bambu Studio's Send dialog would: the choice saved in BambuStudio.conf for this printer, else Studio's default.
`template_dir`	No	Optional template directory override when resolving template_name.
`template_name`	No	Named collar charm template from the local registry. Required unless source_path is provided; resolves source_path automatically.
`slicer_profile`	No	Path to the slicer profile/config file for auto-slicing (optional).
`nozzle_diameter`	No	Nozzle diameter in mm for auto-slicing (default: 0.4)
`flow_calibration`	No	Flow calibration task boolean. Omission resolves Studio settings (auto on P1/P1S); direct MQTT sends false for auto but does not transmit the integer auto mode. The result calibration report distinguishes resolved and transmitted options.
`vibration_calibration`	No	Vibration calibration (default false, as Bambu Studio sends).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.1.93Nov 12, 2026

changedInput schema / properties / flow_calibration / description

Previous value: -"Flow calibration on or off. Omit to send what Bambu Studio's Send dialog would (auto on P1/P1S)."New value: +"Flow calibration task boolean. Omission resolves Studio settings (auto on P1/P1S); direct MQTT sends false for auto but does not transmit the integer auto mode. The result calibration report distinguishes resolved and transmitted options."

Changed3 schema fields changedv1.1.51Nov 2, 2026

changedInput schema / properties / bed_leveling / description

Previous value: -"Enable auto bed leveling (default: true)"New value: +"Auto bed leveling on or off. Omit to send what Bambu Studio's Send dialog would: the choice saved in BambuStudio.conf for this printer, else Studio's default."

changedInput schema / properties / flow_calibration / description

Previous value: -"Enable flow calibration (default: true)"New value: +"Flow calibration on or off. Omit to send what Bambu Studio's Send dialog would (auto on P1/P1S)."

changedInput schema / properties / vibration_calibration / description

Previous value: -"Enable vibration calibration (default: true)"New value: +"Vibration calibration (default false, as Bambu Studio sends)."

Changed1 schema field changedv1.1.42Oct 31, 2026

changedInput schema / properties / bambu_model / enum

Previous value: -[
-  "p1s",
-  "p1p",
-  "p2s",
-  "x1c",
-  "x1e",
-  "a1",
-  "a1mini",
-  "h2d",
-  "h2s",
-  "h2c",
-  "x2d"
-]New value: +[
+  "p1s",
+  "p1p",
+  "p2s",
+  "x1c",
+  "x1e",
+  "a1",
+  "a1mini",
+  "h2d",
+  "h2dpro",
+  "h2s",
+  "h2c",
+  "x2d"
+]

Changed6 schema fields changedv1.1.14Sep 29, 2026

removedInput schema / anyOf

Removed value: -[
-  {
-    "required": [
-      "source_path",
-      "bambu_model"
-    ]
-  },
-  {
-    "required": [
-      "template_name",
-      "bambu_model"
-    ]
-  }
-]

changedInput schema / properties / bambu_model / description

Previous value: -"REQUIRED: Bambu Lab printer model. H2D and H2S are the primary intended paths."New value: +"REQUIRED: Bambu Lab printer model. H2D, H2S, and H2C are the primary intended paths. X2D direct printing is not supported."

changedInput schema / properties / bambu_model / enum

Previous value: -[
-  "p1s",
-  "p1p",
-  "p2s",
-  "x1c",
-  "x1e",
-  "a1",
-  "a1mini",
-  "h2d",
-  "h2s"
-]New value: +[
+  "p1s",
+  "p1p",
+  "p2s",
+  "x1c",
+  "x1e",
+  "a1",
+  "a1mini",
+  "h2d",
+  "h2s",
+  "h2c",
+  "x2d"
+]

changedInput schema / properties / source_path / description

Previous value: -"Path to a prepared collar charm .3mf project or sliced 3MF."New value: +"Path to a prepared collar charm .3mf project or sliced 3MF. Required unless template_name is provided."

changedInput schema / properties / template_name / description

Previous value: -"Named collar charm template from the local registry. Resolves source_path automatically."New value: +"Named collar charm template from the local registry. Required unless source_path is provided; resolves source_path automatically."

addedInput schema / required
```
Added value: +[
+  "bambu_model"
+]
```

First observedv1.1.1May 17, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: the two-part geometry is mapped to fixed AMS slots (inner/smaller to black, outer/larger to white) with no override. It omits the prerequisite AMS loadout and any failure/abort behavior, which matters for a destructive physical print.

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?

A single sentence with no filler; the fixed tray policy is stated up front after the action. Slightly dense with the arrow notation, but every clause carries information.

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?

For a 14-parameter, destructive, physical-print tool with no output schema, one sentence is thin. It covers the distinctive color-mapping behavior but leaves out the required AMS setup, what the prepared project must contain, and how this differs from the generic print tools.

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% across all 14 parameters, so the schema carries parameter meaning on its own. The description adds nothing about source_path vs template_name, model restrictions, or calibration flags, which is acceptable at this coverage level but no more than baseline.

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 ('Print') and a specific resource ('prepared two-part dog collar charm project'), plus the fixed AMS color mapping. It implicitly differentiates from generic siblings like print_3mf by being charm-specific with a hard-coded tray policy, but never names an alternative, so an agent must infer that other models go elsewhere.

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

Usage Guidelines3/5

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

Usage is implied: this is the tool for a prepared collar charm project under the fixed tray policy. There is no explicit when-to-use versus print_3mf / print_3mf_bambu_network / start_print, and no statement of preconditions such as black loaded in AMS 1 slot 1 and white in AMS 2 slot 1.

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

Deploy Server