Skip to main content
Glama
DMontgomery40

bambu-printer-mcp

by DMontgomery40
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

set_fan_speed

Adjust Bambu printer fan speeds by setting a percentage for part, auxiliary, chamber, or other fans. Use it to control cooling during prints or tune airflow for specific materials.

Instructions

Set a Bambu printer fan speed percentage. X2D on macOS, or Linux with the native helper installed, uses Bambu's networking plug-in without UI automation; other models use MQTT.

Input Schema

NameRequiredDescriptionDefault
fanYesFan to control: part, auxiliary, right_auxiliary, chamber, 1, 2, 3, or 10
hostNoHostname or IP of the printer (default: value from env)
speedYesFan speed percentage from 0 to 100
bambu_tokenNoAccess token (default: value from env)
bambu_serialNoSerial number (default: value from env)
confirm_during_printNoRequired for X2D fan changes while a print is running.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.14
    • addedInput schema / properties / confirm_during_print
      Added value: +{
+  "description": "Required for X2D fan changes while a print is running.",
+  "type": "boolean"
+}
    • changedInput schema / properties / fan / description
      Previous value: -"Fan to control: part, auxiliary, chamber, 1, 2, or 3"New value: +"Fan to control: part, auxiliary, right_auxiliary, chamber, 1, 2, 3, or 10"
  2. First observedv1.1.1

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It discloses the platform-dependent transport (X2D/native helper via plug-in, other models via MQTT), which is useful beyond the schema, but omits auth requirements, whether changes are immediate/reversible, and confirmation behavior for in-print changes (the latter is only in the schema).

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?

Two tight sentences, front-loaded with the core action before the mechanism detail. No filler, though the second sentence packs platform detail that could be deferred.

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 mutation tool with no annotations, no output schema, and six parameters, the description is only adequate: it covers the action and transport but leaves auth, side effects, and confirmation semantics (partly schema-covered) unaddressed. There are clear gaps relative to the tool's complexity.

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 all six parameters including enum-like fan values and the confirm_during_print flag. The description adds no parameter-level meaning, so the baseline 3 applies.

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 first sentence gives a clear verb+resource+scope: setting a Bambu printer fan speed percentage. It is distinguishable from siblings like set_print_speed and set_temperature. However, it does not explicitly contrast with those siblings, keeping it short of a 5.

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 transport mechanisms (Bambu networking plug-in vs MQTT) but never states when an agent should choose this tool over alternatives such as set_print_speed. No preconditions or exclusions for invocation are given beyond a platform note that reads as implementation detail.

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

Deploy Server

Other Tools