Skip to main content
Glama
DMontgomery40

bambu-printer-mcp

by DMontgomery40
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

set_temperature

Set a validated bed or nozzle temperature for Bambu Lab printers; positive heating needs fresh telemetry, nozzle heating needs declared material, and zero turns the heater off.

Instructions

Set a checked bed or nozzle temperature. Positive heating requires matching fresh printer telemetry; nozzle heating also requires declared material. Zero turns the heater off.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNoHostname or IP of the printer (default: value from env)
materialNoLoaded material, for example PLA or PETG. Required for positive nozzle heating, including non-RFID spools.
componentYesComponent to heat: bed, nozzle, or extruder
bambu_modelNoPrinter model, required for positive heating unless configured in the environment
bambu_tokenNoAccess token (default: value from env)
temperatureYesFinite target temperature in °C, checked against model/component and declared material limits
bambu_serialNoSerial number (default: value from env)
nozzle_diameterNoInstalled nozzle diameter to compare with printer-reported configuration (default 0.4)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.1.14
    • addedInput schema / properties / bambu_model
      Added value: +{
+  "description": "Printer model, required for positive heating unless configured in the environment",
+  "enum": [
+    "p1s",
+    "p1p",
+    "p2s",
+    "x1c",
+    "x1e",
+    "a1",
+    "a1mini",
+    "h2d",
+    "h2s",
+    "h2c",
+    "x2d"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / material
      Added value: +{
+  "description": "Loaded material, for example PLA or PETG. Required for positive nozzle heating, including non-RFID spools.",
+  "type": "string"
+}
    • addedInput schema / properties / nozzle_diameter
      Added value: +{
+  "description": "Installed nozzle diameter to compare with printer-reported configuration (default 0.4)",
+  "enum": [
+    0.2,
+    0.4,
+    0.6,
+    0.8
+  ],
+  "type": "number"
+}
    • changedInput schema / properties / temperature / description
      Previous value: -"Target temperature in °C"New value: +"Finite target temperature in °C, checked against model/component and declared material limits"
    • addedInput schema / properties / temperature / minimum
      Added value: +0
  2. First observedv1.1.1

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses preconditions (fresh telemetry, declared material for nozzles), that values are checked against model/component/material limits, and that temperature=0 disables the heater. It stops short of describing failure behavior, blocking semantics, or what happens when telemetry is stale beyond 'requires matching fresh'.

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?

Two tightly packed sentences with zero filler, front-loading the primary action before the preconditions and the zero edge case. Every clause adds functional value.

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?

For an 8-parameter mutation tool with no annotations and no output schema, the description covers the critical gating behavior (telemetry freshness, material requirement, limit checks, zero=off). It does not clarify return/confirmation behavior or error handling, but the core operational contract an agent needs is present.

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 params like material, bambu_model, and temperature limits are already fully documented in the schema. The description adds only the zero-disables semantics for temperature, which is a modest supplement. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (Set) and resource (bed or nozzle temperature) with clear scope. It distinguishes itself from siblings like set_fan_speed, set_light, and set_ams_drying by naming exactly what it controls, and even notes the zero case, so an agent needs no schema inspection to know what it does.

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?

The description gives concrete conditions for use: positive heating requires matching fresh telemetry and, for nozzles, a declared material, while zero turns the heater off. This is clear context for when to invoke it as written, but it does not name or contrast any alternative sibling tools for temperature-adjacent tasks.

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