What can you do with this server?

Bambu Printer MCP Server gives AI assistants direct control over Bambu Lab 3D printers, enabling end-to-end workflows from STL manipulation and slicing to file management and printer control. Printer Status & Monitoring * Get real-time status: temperatures, print progress, current layer, time remaining, AMS slot data * Read HMS (Health Management System) error diagnostics * Capture chamber camera snapshots (TCP port 6000 for A1/P1 series; RTSP via ffmpeg for X1/P2S/H2 series) Print Job Control * Start, pause, resume, and cancel print jobs * Upload and print pre-sliced .gcode.3mf files with plate selection, AMS mapping, and calibration flags * Skip objects during a running multi-object print * Auto-match AMS slots by RFID; dry-run AMS resolution without starting a print * Print via FULU OrcaSlicer-bambulab BambuNetwork bridge (cloud or LAN) * Specialized collar charm two-color printing wrapper Printer Settings & Controls * Set print speed (silent/standard/sport/ludicrous) * Set nozzle and bed temperatures; control fans (0–100%) and chamber light * Set airduct mode (cooling/heating) for H2/P2 series * Start/stop AMS filament drying (AMS Pro / AMS-HT); trigger AMS RFID re-read * Clear HMS errors AMS Management * Query live filament inventory with resolved profiles and match confidence * Auto-match 3MF filament requirements against loaded AMS trays File Management * List, upload, and delete files on the printer's SD card via FTPS * Upload G-code content directly to the printer Slicing * Slice STL/3MF files using BambuStudio, OrcaSlicer, PrusaSlicer, Cura, or Slic3r * Slice with saved templates; inspect embedded slicer settings; manage a local template registry STL Manipulation * Scale, rotate, center, lay flat, extend base, merge vertices * Inspect model info (dimensions, vertex/face count) Advanced * Blender MCP bridge for advanced mesh editing (remesh, boolean, decimate, etc.) * List 3MF plate objects for use with skip_objects * Dual transport: stdio (Claude Desktop/Code) or Streamable HTTP * Supports multiple printer models (P1S, X1C, H2D, etc.); requires Developer Mode / LAN-only mode

Which integrations are available for this server?

Enables direct control and monitoring of Bambu Lab 3D printers, supporting status updates, file management via FTPS, and full 3MF/STL print workflows. Integrates with an optional Blender MCP bridge to perform advanced mesh operations and 3D model manipulations. Employs the MQTT protocol for real-time printer communication, allowing for job management and G-code command dispatch.

How do I use bambu-printer-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bambu-printer-mcp check the status of my current print and the nozzle temperature" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

bambu-printer-mcp

by DMontgomery40

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Bambu Printer MCP Server gives AI assistants direct control over Bambu Lab 3D printers, enabling end-to-end workflows from STL manipulation and slicing to file management and printer control.

Printer Status & Monitoring

Get real-time status: temperatures, print progress, current layer, time remaining, AMS slot data
Read HMS (Health Management System) error diagnostics
Capture chamber camera snapshots (TCP port 6000 for A1/P1 series; RTSP via ffmpeg for X1/P2S/H2 series)

Print Job Control

Start, pause, resume, and cancel print jobs
Upload and print pre-sliced .gcode.3mf files with plate selection, AMS mapping, and calibration flags
Skip objects during a running multi-object print
Auto-match AMS slots by RFID; dry-run AMS resolution without starting a print
Print via FULU OrcaSlicer-bambulab BambuNetwork bridge (cloud or LAN)
Specialized collar charm two-color printing wrapper

Printer Settings & Controls

Set print speed (silent/standard/sport/ludicrous)
Set nozzle and bed temperatures; control fans (0–100%) and chamber light
Set airduct mode (cooling/heating) for H2/P2 series
Start/stop AMS filament drying (AMS Pro / AMS-HT); trigger AMS RFID re-read
Clear HMS errors

AMS Management

Query live filament inventory with resolved profiles and match confidence
Auto-match 3MF filament requirements against loaded AMS trays

File Management

List, upload, and delete files on the printer's SD card via FTPS
Upload G-code content directly to the printer

Slicing

Slice STL/3MF files using BambuStudio, OrcaSlicer, PrusaSlicer, Cura, or Slic3r
Slice with saved templates; inspect embedded slicer settings; manage a local template registry

STL Manipulation

Scale, rotate, center, lay flat, extend base, merge vertices
Inspect model info (dimensions, vertex/face count)

Advanced

Blender MCP bridge for advanced mesh editing (remesh, boolean, decimate, etc.)
List 3MF plate objects for use with skip_objects
Dual transport: stdio (Claude Desktop/Code) or Streamable HTTP
Supports multiple printer models (P1S, X1C, H2D, etc.); requires Developer Mode / LAN-only mode

bambu-printer-mcp

npm version License: GPL-2.0 TypeScript Node.js Version GitHub stars Downloads

A Bambu Lab-focused MCP server for controlling Bambu printers, manipulating STL files, and managing end-to-end 3MF print workflows from Claude Desktop, Claude Code, or any MCP-compatible client.

This is a stripped-down, Bambu-only fork of mcp-3D-printer-server. All OctoPrint, Klipper, Duet, Repetier, Prusa Connect, and Creality Cloud support has been removed. What remains is a focused, lean implementation for Bambu Lab hardware.

Local handoff note: see REMOTE-DEPLOYMENT.md for the custom H2D/H2S/H2C patches, per-printer MCP split, and remote deployment plan used in this clone.

What's new in bambu-printer-mcp

This fork adds a substantial set of printer control tools beyond the upstream mcp-3D-printer-server. Everything listed below is unique to this package.

v1.1.0 — AMS auto-match, camera snapshot, pause/resume, skip objects

AMS auto-match by RFID (auto_match_ams on print_3mf) — resolves sliced 3MF filament requirements against live AMS inventory. Handles same-SKU different-color filaments. Dry-run with resolve_3mf_ams_slots.
Structured AMS inventory (get_printer_filaments) — per-tray display names, profile resolution tier (exact-model-nozzle/model/generic/unresolved), match confidence, and a summary with recommended auto-slice filament.
AMS settle-time retry — transparently retries when AMS data hasn't arrived on the first MQTT push from an idle printer.
Camera snapshot (camera_snapshot) — JPEG from the chamber camera. TCP-on-6000 for A1/P1S/P1P, RTSP via ffmpeg for X1/P2S/H2 series.
Pause / resume (pause_print, resume_print) — alongside the existing cancel_print.
Skip objects (skip_objects) — skip specific object IDs during a running multi-object print. IDs from list_3mf_plate_objects.
HMS diagnostics (printer://{host}/hms MCP resource) — read-only error summary with automatic settle retry.
Utility controls — set_print_speed (silent/standard/sport/ludicrous), clear_hms_errors, reread_ams_rfid, set_airduct_mode (cooling/heating for H2/P2).
H2-family-safe print path — correct project_file format with ams_mapping2 parallel array, H2 firmware quirks handled.
BambuStudio CLI auto-flatten (BAMBU_CLI_FLATTEN=true) — works around upstream profile inheritance bugs.
Print collar charm (print_collar_charm) — specialized two-color wrapper with fixed tray policy.

v1.1.1 — AMS dryer control (current)

AMS dryer start/stop (set_ams_drying) — sends print.ams_control MQTT command. Works on heated AMS units (AMS Pro / AMS-HT). Action: start or stop, target by AMS index 0–3.
Same-SKU different-color fix for auto_match_ams.
AMS and HMS settle-time retry for idle printers.
Validation script (scripts/validate-printer.mjs) for live printer testing.

Full changelog at CHANGELOG.md.

Related MCP server: Klipper MCP Server

Description

bambu-printer-mcp is a Model Context Protocol server that gives Claude (or any MCP client) direct control over Bambu Lab 3D printers. The verified end-to-end path is: slice in Bambu Studio, export a .gcode.3mf, hand the path to print_3mf — the server reads the slicer's metadata out of the 3MF, builds the correct AMS mapping, uploads over FTPS, and starts the print via an MQTT project_file command. See docs/SLICING.md for the full recipe and why in-process slicing is not the recommended path.

What this is not. This package intentionally supports only Bambu Lab printers. It does not include adapters for OctoPrint, Klipper (Moonraker), Duet, Repetier, Prusa Connect, or Creality Cloud. If you need multi-printer support, use the parent project mcp-3D-printer-server instead.

Why a separate package? The parent project carries all printer adapters in a single binary. When working exclusively with Bambu hardware, that breadth adds unnecessary weight. This fork strips the project to its Bambu core for a smaller, faster install. Both packages share the same protocol fixes and safety features.

Note on resource usage. STL manipulation loads entire mesh geometry into memory. For large or complex STL files (greater than 10 MB), these operations can be memory-intensive. See General Limitations and Considerations for details.

Features

Get detailed printer status: temperatures (nozzle, bed, chamber), print progress, current layer, time remaining, and live AMS slot data
Query live AMS inventory with resolved Bambu/Orca filament profile paths via get_printer_filaments. Includes per-tray display names, match confidence (high/medium/low/none), resolution tier (exact-model-nozzle/model/generic/unresolved), and a summary with recommended auto-slice filament. Retries automatically when AMS data hasn't arrived yet (common on first MQTT push from idle printers).
List, upload, and delete files on the printer's SD card via FTPS
Capture a JPEG snapshot from the chamber camera. Supports A1, A1 mini, P1S, P1P (TCP-on-6000), and X1, X1C, X1E, P2S, H2, H2S, H2D, H2C, H2D Pro (RTSP via ffmpeg). Requires ffmpeg in PATH for the RTSP path.
Upload and print pre-sliced .gcode.3mf files with full plate selection and calibration flag control (recommended path — see docs/SLICING.md)
Optional single-color auto-slice path via BambuStudio CLI. Set BAMBU_CLI_FLATTEN=true to enable a workaround that flattens BBL profile inheritance before invoking the CLI — works around upstream bugs in BambuStudio CLI mode (#9636, #9968). Single-color smoke is verified on H2S/H2D/X1C/P1S; H2C requires Bambu Studio 2.4.0 or newer and should use BAMBU_MODEL=h2c, not an H2D fallback. H2D two-color CLI slicing is blocked upstream (#10408); use a GUI-sliced .gcode.3mf for that workflow. Default off; Path A (GUI-slice) remains the recommended workflow for non-BBL profiles, multi-color H2 jobs, or first-time prints. See docs/SLICING.md.
Parse AMS mapping from the 3MF's embedded slicer metadata (Metadata/plate_<n>.json + gcode filament header) and send it correctly formatted per the OpenBambuAPI spec, with correct H2S/H2D/H2C ams_mapping2 parallel array format
Auto-match AMS slots by RFID (auto_match_ams flag on print_3mf). Resolves required tray_info_idx from the sliced 3MF against live AMS inventory. Handles same-SKU different-color filaments by matching on (tray_info_idx, tray_color) and tracking already-claimed slots. Dry-run with resolve_3mf_ams_slots before printing.
Cancel, pause, and resume in-progress print jobs via MQTT
Skip specific objects during a running multi-object print via skip_objects (use list_3mf_plate_objects to find object IDs first)
Set print speed mode (silent/standard/sport/ludicrous), clear HMS/print errors, trigger AMS RFID re-read, and control H2/P2 airduct mode (cooling/heating) via MQTT
Start/stop AMS filament drying (set_ams_drying) on heated AMS units (AMS Pro / AMS-HT). Sends print.ams_control MQTT command.
Set nozzle and bed temperature via G-code dispatch over MQTT
Set fan speed (part, auxiliary, chamber) and chamber light mode (on/off/flashing) via MQTT
Read HMS (Health Management System) diagnostics as an MCP resource at printer://{host}/hms — read-only error summary from the printer, with automatic settle retry
Start G-code files already stored on the printer
Collar charm print wrapper (print_collar_charm) — specialized two-color workflow with fixed tray policy for inner (black, AMS 1 slot 1) and outer (white, AMS 2 slot 1) charm parts
STL manipulation: scale, rotate, extend base, merge vertices, center at origin, lay flat, and inspect model info
Slice STL or 3MF files using BambuStudio, OrcaSlicer, PrusaSlicer, Cura, or Slic3r
Inspect slicer settings from a saved 3MF template or extracted profile via get_slice_settings
Enumerate saved slicing templates from the local registry via list_templates
Save templates into the local registry via save_template
Slice directly from a named template via slice_with_template
For simple single-material slices, auto-select the printer's current or first loaded AMS filament when no explicit slicer profile or load_filaments override is provided
Template-driven slicing can reuse a saved 3MF's process settings while still pulling the live printer filament choice over MQTT
Optional Blender MCP bridge for advanced mesh operations
Dual transport: stdio (default, for Claude Desktop / Claude Code) and Streamable HTTP

Installation

Prerequisites

Node.js 18 or higher
npm
BambuStudio (optional -- only needed for slicing) -- download from bambulab.com. Required by slice_stl and print_3mf auto-slice (when a 3MF has no embedded gcode). Not needed if you only print pre-sliced 3MF files. Default path: /Applications/BambuStudio.app/Contents/MacOS/BambuStudio (macOS); set SLICER_PATH if installed elsewhere.

Run without installing (npx)

The fastest way to get started. No global install required:

npx @rowbotik/bambu-printer-mcp

Set environment variables inline or via a .env file in your working directory (see Configuration).

Install globally from npm

npm install -g @rowbotik/bambu-printer-mcp

After installation, the bambu-printer-mcp command is available in your PATH.

Install from source

git clone https://github.com/rowbotik/bambu-printer-mcp.git
cd bambu-printer-mcp
npm install
npm run build
npm link

npm link makes the bambu-printer-mcp binary available globally without publishing to npm.

Configuration

Create a .env file in the directory where you run the server, or pass environment variables directly in your MCP client config. All printer connection variables can also be passed as tool arguments on a per-call basis, which is useful when working with multiple printers.

# --- Bambu printer connection (required for all printer tools) ---
PRINTER_HOST=192.168.1.100        # IP address of your Bambu printer on the local network
BAMBU_SERIAL=01P00A123456789      # Printer serial number (see Finding Your Serial Number below)
BAMBU_TOKEN=your_access_token     # LAN access token from printer touchscreen
# Compatible aliases also accepted:
# BAMBU_PRINTER_HOST / BAMBU_PRINTER_SERIAL / BAMBU_PRINTER_ACCESS_TOKEN

# --- Printer model (CRITICAL for safe operation) ---
BAMBU_MODEL=p1s                   # Your printer model: p1s, p1p, p2s, x1c, x1e, a1, a1mini, h2d, h2s, h2c
# Alias also accepted: BAMBU_PRINTER_MODEL
BED_TYPE=textured_plate           # Bed plate type: textured_plate, cool_plate, engineering_plate, hot_plate, supertack_plate
NOZZLE_DIAMETER=0.4               # Nozzle diameter in mm (default: 0.4)

# --- Slicer configuration (required for slice_stl and print_3mf auto-slice) ---
SLICER_TYPE=bambustudio           # Options: bambustudio, prusaslicer, orcaslicer, cura, slic3r
SLICER_PATH=/Applications/BambuStudio.app/Contents/MacOS/BambuStudio
                                  # Default on macOS. Adjust for your OS and install path.
# Alias also accepted: BAMBU_STUDIO_PATH
SLICER_PROFILE=                   # Optional: path to a slicer profile/config file

# --- Temporary file directory ---
TEMP_DIR=/tmp/bambu-mcp-temp      # Directory for intermediate files. Created automatically if absent.

# --- MCP transport ---
MCP_TRANSPORT=stdio               # Options: stdio (default), streamable-http

# --- Streamable HTTP transport (only used when MCP_TRANSPORT=streamable-http) ---
MCP_HTTP_HOST=127.0.0.1
MCP_HTTP_PORT=3000
MCP_HTTP_PATH=/mcp
MCP_HTTP_STATEFUL=true
MCP_HTTP_JSON_RESPONSE=true
MCP_HTTP_ALLOWED_ORIGINS=http://localhost

# --- Optional Blender MCP bridge ---
BLENDER_MCP_BRIDGE_COMMAND=       # Shell command to invoke your Blender MCP bridge executable

Environment variables reference

Variable	Default	Required	Description
`PRINTER_HOST`	`localhost`	Yes	IP address of the Bambu printer. Alias: `BAMBU_PRINTER_HOST`
`BAMBU_SERIAL`		Yes	Printer serial number. Alias: `BAMBU_PRINTER_SERIAL`
`BAMBU_TOKEN`		Yes	LAN access token. Alias: `BAMBU_PRINTER_ACCESS_TOKEN`
`BAMBU_MODEL`		Yes	Printer model: `p1s`, `p1p`, `p2s`, `x1c`, `x1e`, `a1`, `a1mini`, `h2d`, `h2s`, `h2c`. Required for safe operation -- determines the correct G-code generation. Alias: `BAMBU_PRINTER_MODEL`. If omitted and the MCP client supports elicitation, the server will ask you interactively. Use `h2c` for H2C; do not use `h2d` as a fallback.
`BED_TYPE`	`textured_plate`	No	Bed plate type: `textured_plate`, `cool_plate`, `engineering_plate`, `hot_plate`, `supertack_plate`
`NOZZLE_DIAMETER`	`0.4`	No	Nozzle diameter in mm. Used to select the correct BambuStudio machine preset.
`SLICER_TYPE`	`bambustudio`	No	Slicer to use for slicing operations
`SLICER_PATH`	BambuStudio macOS path	No	Full path to the slicer executable. Alias: `BAMBU_STUDIO_PATH`
`SLICER_PROFILE`		No	Path to a slicer profile or config file
`TEMP_DIR`	`./temp`	No	Directory for intermediate files
`MCP_TRANSPORT`	`stdio`	No	Transport mode: `stdio` or `streamable-http`
`MCP_HTTP_HOST`	`127.0.0.1`	No	HTTP bind address (HTTP transport only)
`MCP_HTTP_PORT`	`3000`	No	HTTP port (HTTP transport only)
`MCP_HTTP_PATH`	`/mcp`	No	HTTP endpoint path (HTTP transport only)
`MCP_HTTP_STATEFUL`	`true`	No	Enable stateful HTTP sessions
`MCP_HTTP_JSON_RESPONSE`	`true`	No	Return structured JSON alongside text responses
`MCP_HTTP_ALLOWED_ORIGINS`		No	Comma-separated list of allowed CORS origins
`BLENDER_MCP_BRIDGE_COMMAND`		No	Command to invoke Blender MCP bridge
`BAMBU_CLI_FLATTEN`	`false`	No	When `true`, the MCP flattens BBL profile inheritance before invoking the BambuStudio CLI. Workaround for upstream issues #9636 / #9968. BBL printers only. Single-color smoke verified on H2S/H2D/X1C/P1S; H2C requires Bambu Studio 2.4.0 or newer. H2D two-color CLI slicing remains blocked by #10408. See docs/SLICING.md.
`BAMBU_PROFILES_ROOT`	derived from `SLICER_PATH`	No	Override path to the BambuStudio `Resources/profiles` directory used by the CLI flattener. Useful for non-standard installs or dev environments.

SuperTack can be passed for pre-sliced print jobs, but BambuStudio CLI slicing currently fails fast for supertack_plate because the accepted CLI bed identifier is not verified. Use a pre-sliced 3MF for SuperTack until this is confirmed.

Usage

Add this server to your MCP client's config (Claude Desktop, Claude Code, Cursor, Codex CLI, or any MCP-compatible client). The config format is the same everywhere -- an mcpServers entry with the command and env vars:

{
  "mcpServers": {
    "bambu-printer": {
      "command": "npx",
      "args": ["-y", "@rowbotik/bambu-printer-mcp"],
      "env": {
        "PRINTER_HOST": "192.168.1.100",
        "BAMBU_SERIAL": "01P00A123456789",
        "BAMBU_TOKEN": "your_access_token",
        "BAMBU_MODEL": "p1s",
        "SLICER_TYPE": "bambustudio",
        "SLICER_PATH": "/Applications/BambuStudio.app/Contents/MacOS/BambuStudio"
      }
    }
  }
}

Where this config lives depends on your client:

Client	Config location
Claude Desktop (macOS)	`~/Library/Application Support/Claude/claude_desktop_config.json`
Claude Desktop (Windows)	`%APPDATA%\Claude\claude_desktop_config.json`
Claude Code (project)	`.mcp.json` in project root
Claude Code (global)	`~/.claude/settings.json`
Cursor	MCP settings in Cursor preferences
Codex CLI	MCP config per Codex docs

Restart your client after editing the config.

Recommended: use with codemode-mcp

For any MCP server with a large tool surface, wrapping it behind codemode-mcp dramatically reduces token usage. Instead of exposing every tool definition to the model (which can consume tens of thousands of tokens per turn), codemode lets the agent write code against a two-tool interface (search() and execute()), loading only the tools it needs on demand.

Anthropic and Cloudflare independently demonstrated this pattern reduces MCP token costs by up to 98%:

Code execution with MCP (Anthropic)
Code Mode: give agents an entire API in 1,000 tokens (Cloudflare)

This applies to all MCP servers, not just this one.

Enabling Developer Mode (Required)

This MCP server communicates directly with your printer over your local network using MQTT and FTPS. For this to work, Developer Mode must be enabled on the printer. Without it, the printer will reject third-party LAN connections even if you have the correct access code.

On H2D/H2-series firmware, the printer may stream push_status data without ever answering the legacy get_version handshake used by older libraries. This fork treats the live status stream as authoritative and does not require that extra ACK before considering the connection usable.

Developer Mode is available on the following firmware versions and later:

Series	Minimum Firmware
P1 Series (P1P, P1S)	`01.08.02.00`
X1 Series (X1C, X1E)	`01.08.03.00`
A1 Series (A1, A1 Mini)	`01.05.00.00`
H2D	`01.01.00.01`

If your firmware is older than these versions, update through Bambu Studio or the Bambu Handy app before proceeding.

Step 1: Navigate to Network Settings

On the printer's touchscreen, go to Settings, then select the Network (WLAN) page. You should see your WiFi network name, IP address, and the LAN Only Mode toggle.

Step 2: Enable LAN Only Mode

Toggle LAN Only Mode to ON. This enables direct local network communication protocols (MQTT on port 8883 and FTPS on port 990) that this server requires.

Important: Enabling LAN Only Mode disconnects the printer from Bambu Lab's cloud services. The Bambu Handy mobile app will stop working while this mode is active. Bambu Studio and OrcaSlicer can still connect over LAN.

Step 3: Enable Developer Mode

Once LAN Only Mode is on, a Developer Mode option appears in the same settings menu. Toggle it ON. This allows third-party clients (like this MCP server) to authenticate and send commands over MQTT.

Step 4: Note the Access Code

The Access Code displayed on the network settings screen is your LAN access token. You will need this value for the BAMBU_TOKEN environment variable.

The access code can be refreshed by tapping the circular arrow icon next to it. If you refresh it, any existing connections using the old code will be disconnected and you will need to update your configuration with the new code.

Finding Your Bambu Printer's Serial Number and Access Token

Two values are required to connect directly to a Bambu Lab printer over your local network: the printer's serial number and its LAN access token (the Access Code from Developer Mode setup above).

Serial number

The serial number is printed on a sticker on the back or underside of the printer. It typically follows one of these formats:

P1 Series: begins with 01P
X1 Series: begins with 01X
A1 Series: begins with 01A

You can also find it on the printer's touchscreen. Navigate to Settings and select the Device Info page:

The Printer line shows your serial number. In Bambu Studio, you can also find it under Device > Device Management in the printer information panel.

LAN access token

The access token is the Access Code shown on the printer's network settings screen. It is separate from your Bambu Cloud account password. If you followed the Developer Mode setup above, you already have this value.

P1 Series (P1P, P1S):

On the printer touchscreen, go to Settings.
Select the Network / WLAN page.
The Access Code is displayed at the bottom of the screen.

X1 Series (X1C, X1E):

On the printer touchscreen, go to Settings.
Select Network.
Enable LAN Only Mode and Developer Mode if not already on.
The Access Code appears on this screen.

A1 and A1 Mini:

Open the Bambu Handy app on your phone.
Connect to your printer.
Navigate to Settings > Network.
The Access Code is shown here.

Your printer must also be logged into a Bambu Cloud account for LAN mode to function. You can verify this on the cloud/account settings screen:

Troubleshooting: If the LAN Only Mode or Developer Mode options are not visible, your printer firmware is likely outdated. Update to the latest firmware version through Bambu Studio or the Bambu Handy app and try again.

AMS (Automatic Material System) Setup

The Bambu AMS is a multi-spool feeder that lets you assign different filaments to different parts of a multi-color or multi-material print. This section explains how AMS slot mapping works with this MCP server.

How AMS slots work

The AMS has 4 slots per unit, numbered 0 through 3. If you have multiple AMS units chained together, the second unit's slots are 4 through 7, and so on. When you slice a model in Bambu Studio or OrcaSlicer, each color/material in the print is assigned to a specific AMS slot.

Automatic AMS mapping from the 3MF

When you slice a model in Bambu Studio, the slicer embeds AMS mapping information inside the 3MF file at Metadata/project_settings.config. The print_3mf tool reads this file automatically and extracts the correct mapping. In most cases, you do not need to specify ams_mapping manually -- the tool handles it.

Manual AMS mapping

If you need to override the embedded mapping (for example, you swapped filament positions since slicing), pass the ams_mapping array to print_3mf:

{
  "three_mf_path": "/path/to/model.3mf",
  "ams_mapping": [0, 2],
  "use_ams": true
}

Each element in the array corresponds to a filament slot used in the print file, in the order they appear in the slicer. The value is the physical AMS slot number (0-based) where that filament is currently loaded. In the example above, the first filament in the print uses AMS slot 0, and the second uses AMS slot 2.

The server pads this array to the 5 elements required by the printer's MQTT protocol. An ams_mapping of [0, 2] becomes [0, 2, -1, -1, -1] on the wire, where -1 indicates unused positions.

Single-material prints

For a single-material print (the most common case), the default mapping is [-1, -1, -1, -1, 0], which tells the printer to pull filament from AMS slot 0. If your filament is in a different slot, specify it:

{
  "three_mf_path": "/path/to/model.3mf",
  "ams_mapping": [2]
}

This tells the printer to use AMS slot 2 for the single filament in the print.

Printing without AMS

If you are using the direct-feed spool holder (no AMS attached) or want to bypass the AMS entirely, set use_ams to false:

{
  "three_mf_path": "/path/to/model.3mf",
  "use_ams": false
}

Auto-match AMS by RFID

For pre-sliced 3MFs that declare filament types, the auto_match_ams flag on print_3mf (or the standalone resolve_3mf_ams_slots dry-run tool) automatically resolves the required filaments against your live AMS inventory. The matcher works as follows:

Reads the required tray_info_idx values from the 3MF's Metadata/slice_info.config and Metadata/plate_<n>.json
Reads your live AMS trays from the printer's MQTT status push
Matches on (tray_info_idx, tray_color) — so two filaments of the same SKU but different colors (e.g. two GFG02 PETG HF spools in black and white) resolve to different slots
Tracks already-claimed slots so two requirements can't collapse onto the same physical position
Falls back to SKU-only matching when the 3MF carries no color data or only one tray of that SKU is loaded

If resolution fails, returns a structured missing report with per-requirement reasons:

no_loaded_match — no AMS tray of that SKU is loaded
color_mismatch — the SKU matches but the loaded color differs
exhausted — all matching trays are already claimed by other requirements
no_sku — the 3MF doesn't declare a tray_info_idx for this filament

Dry-run with resolve_3mf_ams_slots before printing to preview the match without uploading or starting a job.

AMS settle-time handling

The first MQTT status push from an idle printer is often sparse (model/module info only) — AMS slot data arrives on a second push. The server's filament inventory and HMS handlers both retry after a 1.5-second settle window when the expected data isn't present in the first response. This is transparent to the caller.

Checking AMS status

Use get_printer_filaments for the parsed, enriched view (profile paths, display names, match confidence) or get_printer_status for the raw AMS data from the printer:

"What filaments are loaded in my AMS right now?"

Bambu Communication Notes (MQTT and FTP)

Bambu Lab printers do not use a conventional REST API. Instead, they expose two local protocols that this server uses directly:

MQTT (port 8883, TLS): All printer commands and state reports flow over an MQTT broker running on the printer itself. The broker requires your serial number as the client ID and your access token as the password. Commands like starting a print, cancelling a job, and dispatching G-code lines are all MQTT publishes to the device topic. Status data is received by subscribing to the printer's report topic and requesting a push_all refresh. This implementation is based on community reverse engineering documented in the OpenBambuAPI project.

FTPS (port 990, implicit TLS): File operations (upload and directory listing) use FTPS. The printer's SD card is accessible as a filesystem with directories including cache/ (for 3MF and G-code print files), timelapse/, and logs/. Authentication uses the username bblp and your access token as the password.

What this fork fixes

Both this package and the parent project (mcp-3D-printer-server) include fixes for two protocol-level issues in the underlying bambu-js library.

Bug 1: FTP double-path error in bambu-js.

The bambu-js library's sendFile method has a path construction bug. It calls ensureDir to change the working directory into the target directory (e.g., /cache), and then calls uploadFrom with the full relative path including the directory prefix (e.g., cache/file.3mf). The result is that the file lands at the wrong path on the printer (e.g., /cache/cache/file.3mf instead of /cache/file.3mf), and the subsequent print command fails because it references a file that does not exist at the expected path.

This fork bypasses bambu-js for all uploads and uses basic-ftp directly. The upload function (ftpUpload) connects to the printer, resolves the absolute remote path, changes to the correct directory with ensureDir, and then uploads using only the basename -- avoiding the double-path construction entirely.

// From src/printers/bambu.ts
private async ftpUpload(host, token, localPath, remotePath): Promise<void> {
  const client = new FTPClient(15_000);
  await client.access({ host, port: 990, user: "bblp", password: token,
                        secure: "implicit", secureOptions: { rejectUnauthorized: false } });
  const absoluteRemote = remotePath.startsWith("/") ? remotePath : `/${remotePath}`;
  const remoteDir = path.posix.dirname(absoluteRemote);
  await client.ensureDir(remoteDir);
  // basename only -- no double-path
  await client.uploadFrom(localPath, path.posix.basename(absoluteRemote));
  client.close();
}

Bug 2: AMS mapping format in the project_file MQTT command.

The bambu-js library's project file command hardcodes use_ams: true and does not support the ams_mapping field at all. Without the fix, the mapping is a simple array of slot indices (e.g., [0, 2]), which does not match the OpenBambuAPI specification.

According to the OpenBambuAPI spec, P1/A1/X1-series printers use a 5-element ams_mapping array where position i is the project filament index and the value is the AMS slot feeding that filament. For example, a single-filament print from AMS slot 0 sends [0, -1, -1, -1, -1].

This fork sends the project_file command directly via bambu-node (bypassing bambu-js entirely for print initiation) and constructs the mapping in the format the target firmware expects:

// P1/A1/X1-series: 5-element project lookup table
ams_mapping = [0, -1, -1, -1, -1];

// H2S/H2D/H2C: project-length lookup table + parallel ams_mapping2
ams_mapping = [-1, 1, -1, -1];
ams_mapping2 = [
  { ams_id: 255, slot_id: 255 },
  { ams_id: 0, slot_id: 1 },
  { ams_id: 255, slot_id: 255 },
  { ams_id: 255, slot_id: 255 }
];

The command payload also includes all required fields per the OpenBambuAPI spec: param (the internal gcode path within the 3MF), url (the sdcard path), md5 (computed from the plate's embedded gcode), and all calibration flags.

Verified print procedure (H2S, LAN-only, no client cert)

This is the sequence that successfully started a print on an H2S running current (post-Jan 2025) firmware in LAN-only mode. It's documented here because several common approaches fail on this firmware, and this fork's transport is what makes it reliable.

Result: print started in RUNNING state, printer accepted the MQTT project_file command, no client certificate was required. Authentication was plain bblp + LAN access code over TLS with rejectUnauthorized: false.

What doesn't work on stock bambu-cli:

bambu-cli print start <file> and bambu-cli files upload both fail with 522 SSL connection failed: session reuse required. Bambu's FTPS server requires TLS session reuse between the control and data channels, which the Go FTPS client in bambu-cli does not negotiate correctly.
bambu-cli print start --no-upload still opens an FTPS session (to stat the remote file) and hits the same 522.

What works — two-step upload + MQTT dispatch:

Upload the .gcode.3mf via curl (curl's OpenSSL backend negotiates FTPS session reuse correctly):
```
curl -k --ftp-pasv --ssl-reqd \
  -u "bblp:<ACCESS_CODE>" \
  -T /path/to/file.gcode.3mf \
  "ftps://<PRINTER_IP>:990/<remote-name>.gcode.3mf"
```
Keep <remote-name> simple ASCII, ending in .gcode.3mf. The file lands at the FTP root, which corresponds to /data/ on the printer's SD card.

Send the project_file command over MQTT to device/<SERIAL>/request:

import mqtt from "mqtt";
const payload = {
  print: {
    sequence_id: "0",
    command: "project_file",
    param: "Metadata/plate_1.gcode",          // path inside the 3MF
    subtask_name: "<remote-name>.gcode.3mf",
    file: "<remote-name>.gcode.3mf",
    url: "ftp:///<remote-name>.gcode.3mf",    // three slashes, FTP root
    md5: "",
    project_id: "0", profile_id: "0", task_id: "0", subtask_id: "0",
    timelapse: false,
    bed_type: "auto",
    bed_leveling: true, bed_levelling: true,
    flow_cali: true, vibration_cali: true, layer_inspect: true,
    use_ams: true,
    ams_mapping: [0, -1, -1, -1, -1]
  }
};
const client = mqtt.connect(`mqtts://<PRINTER_IP>:8883`, {
  username: "bblp",
  password: "<ACCESS_CODE>",
  rejectUnauthorized: false,
});
client.on("connect", () => {
  client.publish(`device/<SERIAL>/request`, JSON.stringify(payload));
});

Notes:

url must be ftp:///<filename> (three slashes) — the empty host component is required; the printer rejects ftp://<filename> as "unsupported print file path or name".
param uses the internal plate path inside the 3MF (Metadata/plate_1.gcode for plate 1), not a filesystem path.
md5: "" is accepted; populating it is optional.
On AMS-equipped H2 printers, use_ams: false does not suppress mapping lookup if the sliced file declares filaments. The working H2 path is to send use_ams: true plus a valid mapping. For H2, the mapping length must match the project-level filament declaration length, and the populated positions must match plate_<n>.json.filament_ids. Prefer ams_slots at the tool layer and let the server expand it. If no mapping is provided for an H2 pre-sliced job with declared filaments, the server fails before sending; pass explicit ams_slots, raw ams_mapping, or auto_match_ams: true.
No client X.509 certificate was needed. The earlier assumption that post-Jan 2025 firmware mandates mTLS on all models does not hold for the H2S in LAN mode — user/password over TLS is sufficient.
The MCP server's ftpUpload helper (basic-ftp with secure: "implicit" and a short idle timeout) performs the equivalent upload natively and is the preferred path when using the server itself; the curl form is the manual-debug equivalent.

Available Tools

STL Manipulation Tools

All STL tools load the full mesh geometry into memory. For files larger than 10 MB, monitor memory usage and prefer testing on smaller files first.

get_stl_info

Inspect an STL file without modifying it. Returns bounding box dimensions, face count, vertex count, and model center.

{
  "stl_path": "/path/to/model.stl"
}

scale_stl

Scale an STL model along individual axes. Omit any axis to leave it unchanged (defaults to 1.0).

{
  "stl_path": "/path/to/model.stl",
  "scale_x": 1.5,
  "scale_y": 1.5,
  "scale_z": 1.0
}

For uniform scaling, set all three axes to the same value:

{
  "stl_path": "/path/to/model.stl",
  "scale_x": 2.0,
  "scale_y": 2.0,
  "scale_z": 2.0
}

rotate_stl

Rotate an STL model around one or more axes. Angles are in degrees. Omitted axes default to 0.

{
  "stl_path": "/path/to/model.stl",
  "angle_x": 0,
  "angle_y": 0,
  "angle_z": 90
}

extend_stl_base

Add solid geometry underneath the model to increase its base height. Useful for improving bed adhesion on models with a small or unstable footprint.

{
  "stl_path": "/path/to/model.stl",
  "extension_height": 3.0
}

extension_height is in millimeters.

merge_vertices

Merge vertices that are closer together than the specified tolerance. This can close small gaps in a mesh and slightly reduce file size. Useful as a cleanup step before slicing.

{
  "stl_path": "/path/to/model.stl",
  "tolerance": 0.01
}

tolerance is in millimeters and defaults to 0.01 if omitted.

center_model

Translate the model so the center of its bounding box sits at the world origin (0, 0, 0). Useful before applying transformations or exporting for use in another tool.

{
  "stl_path": "/path/to/model.stl"
}

lay_flat

Identify the largest flat surface on the model and rotate the model so that face is oriented downward on the XY plane (Z = 0). This is a common preparation step before slicing to minimize the need for supports.

{
  "stl_path": "/path/to/model.stl"
}

Note: this works best on models with a clearly dominant flat face. Results on organic or rounded shapes may be unpredictable.

Printer Control Tools

All printer tools accept optional host, bambu_serial, and bambu_token arguments. If omitted, values fall back to the environment variables PRINTER_HOST, BAMBU_SERIAL, and BAMBU_TOKEN. Passing them explicitly is useful when working with more than one printer.

The server also accepts the alias variables BAMBU_PRINTER_HOST, BAMBU_PRINTER_SERIAL, and BAMBU_PRINTER_ACCESS_TOKEN, plus BAMBU_PRINTER_MODEL and BAMBU_STUDIO_PATH.

get_printer_status

Retrieve current printer state including temperatures, print progress, layer count, time remaining, and AMS slot data. Internally sends a push_all MQTT command to force a fresh status report before reading cached state.

{
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

Returns a structured object with fields including status (gcode_state string), temperatures.nozzle, temperatures.bed, temperatures.chamber, print.progress, print.currentLayer, print.totalLayers, print.timeRemaining, and ams (raw AMS data from the printer).

get_printer_filaments

Read the live AMS inventory and resolve each loaded tray to Bambu Studio filament profile JSON paths when bambu_model is known. The result includes a summary, per-slot display labels, profile match confidence, and a recommended load_filaments value for simple single-material CLI slicing.

{
  "bambu_model": "h2d",
  "nozzle_diameter": "0.4",
  "host": "192.168.1.100",
  "bambu_serial": "094...",
  "bambu_token": "your_access_token"
}

High-signal fields:

summary.loaded_slots, summary.resolved_profile_slots, summary.unresolved_loaded_slots, summary.empty_slots
trays[].display_name, trays[].tray_color, trays[].remain_percent
trays[].resolved_profile_path
trays[].profile_resolution: exact-model-nozzle, model, generic, or unresolved
trays[].match_confidence: high, medium, low, or none
recommended.load_filaments: the profile path the MCP will use for auto-slicing when no explicit filament override is provided

list_printer_files

List files stored on the printer's SD card. Scans the cache/, timelapse/, and logs/ directories and returns both a flat list and a directory-grouped breakdown.

{
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

camera_snapshot

Capture a single JPEG frame from the printer's chamber camera. Read-only.

Two transports are wired in, picked by bambu_model:

TCP-on-6000 for A1, A1 mini, P1S, P1P. Native protocol per OpenBambuAPI/video.md: TLS on port 6000, 80-byte auth packet (bblp + access token), repeating 16-byte frame header + JPEG payload.
RTSP for X1, X1 Carbon, X1E, P2S and H2, H2S, H2D, H2C, H2D Pro. Shells out to ffmpeg with rtsps://bblp:<token>@<host>:322/streaming/live/1 -frames:v 1. The H2 series wasn't documented in OpenBambuAPI's video.md but its firmware uses the same RTSP endpoint as X1 (verified live against an H2S, 2026-04-27).

Requires ffmpeg in PATH for the RTSP path. Install with brew install ffmpeg on macOS. Configure a trusted custom binary with the server-side FFMPEG_PATH environment variable, or set MCP_ALLOW_EXECUTABLE_ARG=1 before using the ffmpeg_path tool argument. The TCP-on-6000 path uses native Node TLS and does not require ffmpeg.

{
  "save_path": "/tmp/snap.jpg",
  "timeout_ms": 8000,
  "bambu_model": "h2s",
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

Returns { status, format: "image/jpeg", sizeBytes, base64, savedTo?, transport }. transport is "tcp-6000" or "rtsps-322" so callers can tell which path produced the frame. Pass save_path to also write the bytes to disk; otherwise only the base64 payload is returned.

delete_printer_file

Delete a single file from the printer's SD card via FTPS. Destructive. Requires confirm: true — without it the call returns status: "skipped" and does not contact the printer. Path traversal segments (..) are rejected. Only files under cache/, timelapse/, and logs/ can be deleted.

{
  "filename": "old_print.gcode.3mf",
  "confirm": true,
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

A bare filename defaults to cache/<filename>. To target other directories pass a relative path:

{ "filename": "timelapse/2026-04-26_12-00.mp4", "confirm": true }
{ "filename": "logs/printer.log", "confirm": true }

upload_gcode

Write G-code content from a string directly to the printer's cache/ directory. The content is written to a temporary file and uploaded via FTPS.

{
  "filename": "calibration.gcode",
  "gcode": "G28\nM104 S210\nG1 X100 Y100 Z10 F3000\n",
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

upload_file

Upload a local file (G-code or 3MF) to the printer. If print is true and the file is a .gcode file, start_print_job is called automatically after a successful upload. For .3mf files, upload completes normally but you must use print_3mf to initiate the print (which handles plate selection and metadata).

{
  "file_path": "/Users/yourname/Downloads/part.3mf",
  "filename": "part.3mf",
  "print": false,
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

start_print_job

Start printing a .gcode file that is already on the printer's SD card. Do not use this for .3mf files -- use print_3mf instead, which handles the project_file MQTT command with proper metadata.

{
  "filename": "cache/calibration.gcode",
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

If filename does not include a directory prefix, the server prepends cache/ automatically.

cancel_print

Cancel the currently running print job. Sends an UpdateState MQTT command with state: "stop". Not resumable — use pause_print if you may want to continue.

{
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

pause_print

Pause the currently running print job. Sends an UpdateState MQTT command with state: "pause". Resumable via resume_print.

{
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

resume_print

Resume a paused print job. Sends an UpdateState MQTT command with state: "resume".

{
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

clear_hms_errors

Clear HMS or print error state on the printer. Sends Bambu's clean_print_error MQTT command.

{
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

set_print_speed

Set the active print speed mode. Accepted mode values are silent, standard, sport, ludicrous, or their numeric equivalents 1, 2, 3, and 4.

{
  "mode": "sport",
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

set_airduct_mode

Set H2/P2 airduct mode to cooling or heating. This is intended for supported printers only.

{
  "mode": "cooling",
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

reread_ams_rfid

Trigger a Bambu AMS RFID re-read for one AMS slot. This can move AMS filament; use it only when the printer is idle and unloaded.

{
  "ams_id": 0,
  "slot_id": 1,
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

set_temperature

Set the target temperature for the bed or nozzle. Dispatches an M140 (bed) or M104 (nozzle) G-code command via MQTT. Valid range is 0 to 300 degrees Celsius. Accepted values for component are bed, nozzle, extruder, tool, and tool0.

{
  "component": "nozzle",
  "temperature": 220,
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

set_fan_speed

Set a printer fan speed from 0 to 100 percent. Accepted fan values are part, auxiliary, chamber, 1, 2, and 3.

{
  "fan": "chamber",
  "speed": 40,
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

set_light

Set a printer light node mode. Common Bambu firmware reports the chamber light as chamber_light; valid modes are on, off, and flashing.

{
  "light": "chamber_light",
  "mode": "on",
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

skip_objects

Skip specific object IDs during a running multi-object print. Use list_3mf_plate_objects on the sliced 3MF to find the IDs first.

{
  "object_ids": [6495, 6496],
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

set_ams_drying

Start or stop the AMS filament drying cycle on heated AMS units (AMS Pro / AMS-HT). The action parameter accepts start or stop. The ams_id must be an integer from 0 to 3.

{
  "action": "start",
  "ams_id": 0,
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token"
}

To stop drying:

{
  "action": "stop",
  "ams_id": 0
}

print_3mf

The primary tool for starting a Bambu print. Recommended input: a pre-sliced .gcode.3mf exported from Bambu Studio — see docs/SLICING.md. This tool handles the complete workflow:

Checks whether the 3MF contains embedded G-code (Metadata/plate_<n>.gcode entries).
If no G-code is found, attempts to auto-slice via the configured slicer. This fallback is unreliable in practice (stale profiles, leftover multi-filament declarations) — prefer pre-slicing in Bambu Studio.
Parses the sliced 3MF to extract the correct plate file and compute its MD5 hash.
Also parses Metadata/project_settings.config to read AMS mapping embedded by Bambu Studio.
Uploads the 3MF to the printer's cache/ directory via FTPS using basic-ftp directly (avoiding the bambu-js double-path bug).
Sends the correct MQTT print command for the target printer family. For H2S/H2D/H2C that means project_file with project-length ams_mapping, parallel ams_mapping2, and H2-compatible calibration flags.

{
  "three_mf_path": "/Users/yourname/Downloads/bracket.3mf",
  "bambu_model": "p1s",
  "bed_type": "textured_plate",
  "host": "192.168.1.100",
  "bambu_serial": "01P00A123456789",
  "bambu_token": "your_access_token",
  "bed_leveling": true,
  "flow_calibration": true,
  "vibration_calibration": true,
  "timelapse": false,
  "use_ams": true,
  "ams_mapping": [0, 1]
}

bambu_model is required -- it ensures the slicer generates G-code for the correct printer. Using the wrong model can cause the bed to crash into the nozzle. If bambu_model is not provided in the tool call and BAMBU_MODEL is not set in the environment, the server will ask you interactively via MCP elicitation (if your client supports it) or return a clear error.

bed_type defaults to textured_plate if omitted. ams_slots is the preferred override input; ams_mapping remains the raw escape hatch. On AMS-equipped H2 printers, use_ams: false does not suppress mapping lookup if the sliced file declares filaments. If no mapping is provided for an H2 pre-sliced job with declared filaments, the server fails before sending; pass explicit ams_slots, raw ams_mapping, or auto_match_ams: true.

Set auto_match_ams: true to match the sliced 3MF's tray_info_idx values against the live AMS inventory and use the matching ams_slots. The matcher joins on (tray_info_idx, tray_color) and tracks already-claimed slots, so prints with two filaments of the same SKU but different colors (e.g. two GFG02 PETG HF in black and white) resolve correctly. Falls back to SKU-only when the 3MF's filament has no color set or only one tray of that SKU is loaded. Returns a structured missing report (reason: "no_loaded_match" | "color_mismatch" | "exhausted" | "no_sku") when a filament can't be resolved. Ignored when you provide ams_slots or ams_mapping explicitly.

Layer height, nozzle temperature, and other slicer parameters cannot be overridden via this tool -- they are baked into the 3MF's G-code at slice time. Apply those settings in your slicer before generating the 3MF.

resolve_3mf_ams_slots

Dry-run the AMS match without uploading or starting a print. The tool reads Metadata/plate_<n>.json and Metadata/slice_info.config, then compares required tray_info_idx values against live AMS trays.

{
  "three_mf_path": "/Users/yourname/Downloads/bracket.gcode.3mf",
  "bambu_model": "h2d",
  "host": "192.168.1.100",
  "bambu_serial": "094...",
  "bambu_token": "your_access_token"
}

list_3mf_plate_objects

List object IDs from a sliced 3MF plate. Use this before skip_objects so you pass real Bambu object IDs instead of display-order guesses.

{
  "three_mf_path": "/Users/yourname/Downloads/bracket.gcode.3mf",
  "plate_index": 0
}

print_collar_charm

High-level wrapper for a prepared two-part dog-collar-charm workflow. This tool is intentionally specialized: it expects a prepared two-part charm project and applies a fixed tray policy.

Smaller inner object -> black -> AMS 1 slot 1
Larger outer object -> white -> AMS 2 slot 1

The tool will:

Resolve a local .3mf or template_name.
Auto-slice if the 3MF is still an unsliced project.
Inspect Metadata/plate_1.json to identify the smaller inner part and larger outer part.
Preflight the required AMS trays on the printer.
Dispatch the print through the existing H2-safe print3mf path using ams_slots.

{
  "template_name": "collars/letter_charm_a",
  "bambu_model": "h2d",
  "host": "192.168.1.100",
  "bambu_serial": "03W09C123456789",
  "bambu_token": "your_access_token",
  "bed_leveling": true,
  "flow_calibration": true,
  "vibration_calibration": true,
  "timelapse": false
}

You can also pass source_path directly instead of template_name.

This wrapper currently assumes:

the input is a prepared two-part charm .3mf, not a bare STL that needs color-region generation
the selected plate has exactly 2 objects
the selected plate has exactly 2 used filament positions
the smaller object is the inner insert/letter and the larger object is the outer body

If the project does not match those assumptions, the tool fails fast with a structured error instead of guessing. The role-to-color and color-to-tray mapping is isolated in code so the next version can evolve toward customer-requested colors without replacing the whole wrapper.

Slicing Tools

Note: the verified workflow is to slice in Bambu Studio (GUI) and feed the resulting .gcode.3mf to print_3mf. The CLI-driven slicing tools below (slice_stl, slice_with_template) work but are sensitive to profile drift and are not the recommended path for production prints. See docs/SLICING.md.

list_templates

List saved templates from the local registry directory. You can override the registry root with BAMBU_TEMPLATE_DIR.

{}

Each result includes the template name, absolute path, source type, and relative path inside the registry. You can then pass template_name to get_slice_settings, slice_stl, or print_3mf instead of a raw path.

save_template

Copy a local 3mf, json, or .config file into the template registry and register it under a reusable template name.

{
  "source_path": "/path/to/sliced_project.3mf",
  "template_name": "collars/p1p_petg_default"
}

This creates the destination under the template registry directory and makes it available immediately to list_templates, get_slice_settings, slice_with_template, slice_stl, and print_3mf.

get_slice_settings

Inspect the slicer settings embedded in a saved 3MF template or in an extracted JSON/config profile without slicing anything.

{
  "template_name": "h2s_template"
}

This returns a compact summary of the high-signal settings such as printer preset, default print profile, filament profiles, layer height, infill density, shell counts, support mode, and bed type. It accepts either source_path or template_name. For 3MF inputs it also writes the extracted settings blob to a temp path so the result can be reused directly.

slice_with_template

Slice an STL or 3MF using a named template from the local registry. This is a higher-level wrapper over slice_stl for template-based workflows.

{
  "stl_path": "/path/to/model.stl",
  "template_name": "collars/p1p_petg_default",
  "bambu_model": "p1p"
}

This uses the named template as the slicing profile source and still supports live printer filament selection unless you explicitly override load_filaments. The template settings are applied at slice time, and the later print_3mf step computes H2-safe AMS mapping from the newly sliced output.

slice_stl

Slice an STL or 3MF file using an external slicer and return the path to the output file. The output is a sliced 3MF (for BambuStudio and OrcaSlicer) or a G-code file (for PrusaSlicer, Cura, Slic3r).

{
  "stl_path": "/path/to/model.stl",
  "slicer_type": "bambustudio",
  "slicer_path": "/Applications/BambuStudio.app/Contents/MacOS/BambuStudio",
  "slicer_profile": "/path/to/profile.ini"
}

slicer_type options: bambustudio, orcaslicer, prusaslicer, cura, slic3r. When omitted, the value from the SLICER_TYPE environment variable is used (default: bambustudio).

slicer_path and slicer_profile fall back to the SLICER_PATH and SLICER_PROFILE environment variables when omitted. Per-call slicer_path overrides require MCP_ALLOW_EXECUTABLE_ARG=1.

You can provide either template_3mf_path or template_name when you want to slice from a saved template. template_name resolves through the local template registry directory configured for the server.

For printing on a Bambu printer, the recommended workflow is: slice with bambustudio to get a sliced 3MF, then pass that output path to print_3mf.

BambuStudio Slicer Options

When slicer_type is bambustudio (the default), these additional parameters are available on slice_stl:

Parameter	Type	Description
`uptodate`	boolean	Update 3MF configs to latest BambuStudio presets
`repetitions`	number	Number of copies to print
`orient`	boolean	Auto-orient model for optimal printability
`arrange`	boolean	Auto-arrange objects on the build plate
`ensure_on_bed`	boolean	Lift floating models onto the bed
`clone_objects`	string	Clone counts per object, comma-separated (e.g. `"1,3,1,10"`)
`skip_objects`	string	Object indices to skip, comma-separated (e.g. `"3,5,10"`)
`load_filaments`	string	Filament profile paths, semicolon-separated
`load_filament_ids`	string	Filament-to-object mapping, comma-separated
`enable_timelapse`	boolean	Enable timelapse-aware slicing
`allow_mix_temp`	boolean	Allow mixed-temperature filaments on one plate
`scale`	number	Uniform scale factor
`rotate`	number	Z-axis rotation in degrees
`rotate_x`	number	X-axis rotation in degrees
`rotate_y`	number	Y-axis rotation in degrees
`min_save`	boolean	Produce smaller output 3MF (faster uploads)
`skip_modified_gcodes`	boolean	Ignore stale custom gcodes in the 3MF
`slice_plate`	number	Which plate to slice (0 = all plates, default: 0)

Example: Slice with auto-orient and 3 copies

{
  "stl_path": "/path/to/model.stl",
  "bambu_model": "p1s",
  "orient": true,
  "arrange": true,
  "repetitions": 3
}

Smart Defaults (print_3mf auto-slice)

When print_3mf detects an unsliced 3MF and auto-slices it, these defaults are applied automatically:

uptodate: true -- prevents stale config bugs from downloaded 3MFs
ensure_on_bed: true -- safety net, lifts floating models onto the bed
min_save: true -- smaller output for faster FTP uploads to the printer
skip_modified_gcodes: true -- strips custom gcodes from other users' profiles

These defaults keep you safe when printing downloaded models. When calling slice_stl directly, you have full control over every flag.

Advanced Tools

blender_mcp_edit_model

Send a set of named edit operations (remesh, boolean, decimate, etc.) to a Blender MCP bridge command for advanced mesh work that goes beyond what the built-in STL tools support.

When execute is false (the default), the tool returns the payload that would be sent without running anything -- useful for previewing what would be dispatched.

When execute is true, the server invokes the configured bridge command with the payload as a JSON-encoded environment variable (MCP_BLENDER_PAYLOAD). Configure it with BLENDER_MCP_BRIDGE_COMMAND; per-call bridge_command overrides require MCP_ALLOW_EXECUTABLE_ARG=1.

{
  "stl_path": "/path/to/model.stl",
  "operations": ["remesh", "decimate:0.5", "boolean_union:/path/to/other.stl"],
  "execute": false
}

{
  "stl_path": "/path/to/model.stl",
  "operations": ["remesh"],
  "bridge_command": "/usr/local/bin/blender-mcp-bridge",
  "execute": true
}

Available Resources

Resources follow the MCP resource protocol and can be read by calling ReadResource with a URI. The server also lists them via ListResources.

Printer resources

printer://{host}/status -- Current printer status. Equivalent to calling get_printer_status. Returns a JSON object with temperature, progress, layer, AMS, and raw state data.
printer://{host}/files -- File listing for the printer's SD card. Equivalent to calling list_printer_files. Returns files grouped by directory.
printer://{host}/hms -- HMS and error diagnostics from the latest status payload. Returns connection state, printer status, explicit HMS payloads when present, and shallow raw fields whose names indicate errors, failures, warnings, or HMS data.

Example: To read the status of the default printer, use URI printer://192.168.1.100/status. The host segment must match a configured printer IP; the server uses PRINTER_HOST if the default URI template is used.

Example Commands for Claude

After connecting the MCP server in Claude Desktop or Claude Code, you can ask Claude to perform these operations directly in conversation.

Printer status and control

"What is the current status of my Bambu printer?"
"What temperature is the bed at right now?"
"Show me the files on my printer's SD card."
"Cancel the current print job."
"Set the nozzle temperature to 220 degrees."
"Set the bed to 65 degrees."
"Turn the chamber light on."
"Set the chamber fan to 40 percent."
"List the object IDs in this sliced 3MF."
"Skip object 6495 on the current print."
"Start the AMS drying cycle on AMS 0."
"Stop drying on AMS 1."
"Match the AMS slots for this 3MF against my loaded filaments without printing."
"Auto-match AMS slots and print this 3MF."
"Take a camera snapshot of the print bed."
"Show me the HMS error codes on the printer."
"What speed mode is the printer in?"
"Set the airduct to cooling mode."

Printing 3MF files

"Print the file at ~/Downloads/bracket.3mf on my Bambu printer."
"Upload bracket.3mf to the printer and start printing with AMS slots 0 and 1."
"Print my_model.3mf with bed leveling enabled and vibration calibration off."
"Upload this 3MF without printing it yet."
"Slice model.stl with BambuStudio and then print the result."

STL manipulation

"What are the dimensions of this STL file?"
"Scale model.stl to twice its current size."
"Scale this model so it is 150% as wide but stays the same height."
"Rotate this STL 90 degrees around the Z axis."
"Extend the base of this model by 3mm so it sticks to the bed better."
"Center this model at the origin."
"Orient this model so its largest flat face is on the bottom."
"Merge any near-duplicate vertices in this STL to clean it up."

Combined workflows

"Rotate model.stl 45 degrees around Z, extend the base by 2mm, then print it on my Bambu P1S."
"Take this unsliced 3MF, slice it with BambuStudio, and print the result."
"Scale this part to 80% of its size, lay it flat, and start a print."

Bambu Lab Printer Limitations

Understanding these constraints will help you avoid frustrating errors and set appropriate expectations.

Printable 3MF required for print_3mf. The print_3mf tool expects a sliced 3MF containing at least one Metadata/plate_<n>.gcode entry. If you pass an unsliced 3MF (one exported from a CAD tool without slicing), the server will attempt to auto-slice it using the configured slicer — but this fallback is brittle and the recommended workflow is to pre-slice in Bambu Studio and pass the resulting .gcode.3mf. See docs/SLICING.md for the full procedure.
Layer height, temperature, and slicer settings are baked in. The project_file MQTT command tells the printer which plate to run. It does not support overriding layer height, temperature targets, infill percentage, or other slicing parameters at print time. These must be set in your slicer before generating the 3MF.
G-code and 3MF jobs use different command paths. start_print_job sends a GCodeFileCommand over MQTT and is intended only for plain G-code files stored in the cache/ directory. .3mf files must go through print_3mf, which sends the project_file command with plate selection, MD5 verification, and AMS mapping. Mixing these up will result in the printer either ignoring the command or displaying an error.
Temperature commands depend on printer state. set_temperature dispatches M104 or M140 G-code via MQTT. Whether the printer accepts these commands depends on its current firmware version and operational state. Some printer states (such as the idle screen with AMS management open) may ignore or queue the commands.
Real-time status has latency. get_printer_status sends a push_all MQTT request and waits up to 1.5 seconds for a response before reading cached state. If the printer is not responding quickly (busy, sleeping, or transitioning states), you may see slightly stale data. There is no persistent event subscription in this server -- each status call is a fresh request.
LAN mode required. All operations require the printer to be on the same local network as the machine running this server. Cloud-only or remote access setups are not supported. If your printer is connected only via Bambu Cloud and LAN mode is disabled, connection will fail.
Self-signed TLS certificate. The printer's FTPS server uses a self-signed certificate. The basic-ftp client is configured with rejectUnauthorized: false to accept it. This is standard for local network Bambu connections but assumes a trusted local network environment.

General Limitations and Considerations

Memory usage

STL manipulation tools load the entire mesh into memory as Three.js geometry. For large files:

Files over 10 MB can consume several hundred MB of RAM during processing.
Running multiple operations sequentially on large files may cause memory to accumulate between garbage collection cycles.
If you encounter out-of-memory errors, try splitting large operations or working with smaller/simplified meshes.
The server has no built-in memory cap. On constrained systems, set the TEMP_DIR to a fast local path and avoid processing multiple large files concurrently.

STL manipulation limitations

lay_flat identifies the largest flat face by analyzing surface normals. It works reliably on mechanical parts with clear flat faces and less reliably on organic or curved models where no single dominant face exists.
extend_stl_base adds a new rectangular solid beneath the model. For models with complex or non-planar undersides, the result may include gaps or intersections at the join. Review the modified STL before printing.
merge_vertices uses a distance tolerance to identify near-duplicate vertices. Setting the tolerance too high can alter model geometry. The default of 0.01 mm is safe for most models.
Non-manifold meshes (meshes with holes, overlapping faces, or internal geometry) may produce unpredictable results for any transformation operation. Use a mesh repair tool (Meshmixer, PrusaSlicer's repair function, or Bambu Studio's repair option) before working with problematic files.

Performance considerations

Slicing with BambuStudio CLI can take 30 seconds to several minutes depending on model complexity, layer height, and your system's CPU. The slice_stl call is synchronous and will block until the slicer process completes.
FTPS uploads for large 3MF files (multi-plate prints, high-detail models) may take 15 to 60 seconds depending on your local network speed.
MQTT connections are pooled by host + serial key. The first call to any printer tool in a session establishes the MQTT connection; subsequent calls reuse it. If the connection drops (printer power cycled, network interruption), the next call will reconnect automatically.

License

GPL-2.0. See LICENSE for the full text.

This project is a fork of mcp-3D-printer-server by David Montgomery, also GPL-2.0.

Acknowledgements

Some printer command surfaces and workflow priorities were informed by Bambuddy, an AGPL-3.0 Bambu Lab printer management project. This project does not vendor Bambuddy code.

Available Tools

41 tools

bambu_network_bridge_statusC

Inspect or probe the FULU OrcaSlicer-bambulab BambuNetwork bridge runtime used for cloud and restored BambuNetwork printing.

ParametersJSON Schema

Name	Required	Description
`connect`	No	When true, start the bridge command and run a handshake plus agent initialization probe.
`bridge_command`	No	Override command for the FULU bridge host or macOS/WSL wrapper; defaults to BAMBU_NETWORK_BRIDGE_COMMAND.
`bambu_network_config_dir`	No	Config/log directory used by the BambuNetwork agent; defaults to BAMBU_NETWORK_CONFIG_DIR or a user config directory.
`country_code`	No	BambuNetwork country code, such as US, used by the agent during startup.
`user_info`	No	Optional BambuNetwork user_info JSON string to pass to net.change_user after the agent starts.
`timeout_ms`	No	Bridge request timeout in milliseconds for the connect probe.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It fails to state whether the tool is read-only, changes state, requires authentication, or has side effects. 'Inspect or probe' implies a read operation but is not explicit, leaving safety unknown.

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?

The description is a single sentence of 20 words, efficiently conveying the core purpose without wasted verbiage. It is front-loaded with the action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters, no output schema, and no annotations, the description is too minimal. It does not explain the impact of parameters (e.g., what happens with 'connect' true/false), expected output format, or default behavior when no parameters are provided. This leaves significant gaps for the agent.

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 100% with descriptive parameter names and inline descriptions. The tool description adds no extra semantic value beyond the schema. Per the guideline, this earns a baseline of 3.

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 uses specific verbs 'inspect or probe' and identifies the resource as the 'FULU OrcaSlicer-bambulab BambuNetwork bridge runtime'. It adds context about cloud and restored printing. However, it does not explicitly differentiate from sibling tools like 'bambu_network_call' or general status tools, leaving some ambiguity.

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?

No guidance on when to use this tool over alternatives (e.g., 'bambu_network_call' or 'get_fleet_status'). No conditions, prerequisites, or exclusions are mentioned. The agent must infer usage from the name and description alone.

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

bambu_network_callB

Call a raw FULU OrcaSlicer-bambulab BambuNetwork bridge method, optionally with an initialized network agent injected into the payload.

ParametersJSON Schema

Name	Required	Description
`method`	Yes	FULU bridge method name, for example bridge.handshake, net.is_user_login, or net.get_user_selected_machine.
`payload`	No	JSON payload passed to the bridge method.
`with_agent`	No	When true, initialize a BambuNetwork agent and add its agent id to the payload before calling the method.
`bridge_command`	No	Override command for the FULU bridge host or macOS/WSL wrapper; defaults to BAMBU_NETWORK_BRIDGE_COMMAND.
`bambu_network_config_dir`	No	Config/log directory used by the BambuNetwork agent; defaults to BAMBU_NETWORK_CONFIG_DIR or a user config directory.
`country_code`	No	BambuNetwork country code, such as US, used by the agent during startup.
`user_info`	No	Optional BambuNetwork user_info JSON string to pass to net.change_user after the agent starts.
`timeout_ms`	No	Bridge request timeout in milliseconds.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must fully convey behavioral traits. It mentions the raw nature and optional agent injection but fails to disclose destructiveness, authentication needs, side effects, or rate limits, leaving significant gaps.

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?

The description is a single, front-loaded sentence with no waste. It conveys the essential purpose efficiently, earning top marks for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters (including nested objects) and no output schema, the one-sentence description is insufficient. It does not explain how to compose payloads, what methods are valid, or the implications of with_agent, leaving the agent under-informed.

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 parameters. The tool description adds no additional parameter context beyond what the schema provides, thus baseline score of 3 is appropriate.

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?

The description uses a specific verb ('call') and identifies the exact resource ('raw FULU OrcaSlicer-bambulab BambuNetwork bridge method'), clearly distinguishing it from higher-level sibling tools like print, slice, or bambu_network_bridge_status.

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?

No guidance is provided on when to use this tool versus alternatives in the sibling list, such as using a dedicated higher-level tool instead of a raw bridge method, or any prerequisites or exclusions.

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

blender_mcp_edit_modelB

Send STL-edit instructions to a Blender MCP bridge command for advanced model edits

ParametersJSON Schema

Name	Required	Description
`stl_path`	Yes	Path to the local STL file
`operations`	Yes	Ordered edit operations for Blender (e.g. remesh, boolean, decimate)
`bridge_command`	No	Override command for invoking Blender MCP bridge
`execute`	No	Execute bridge command (true) or return payload only (false)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It describes the action as 'Send STL-edit instructions' but does not disclose whether the operation is destructive, whether Blender must be running, what happens on failure, or any side effects. The description is too vague for behavioral context.

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?

A single sentence that efficiently conveys the core purpose without filler. Every word is necessary and front-loaded with the key verb and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return behavior, prerequisites (like Blender being running), or how it relates to the many sibling tools. A user would need additional knowledge to use 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% with each parameter having a description (e.g., 'Path to the local STL file', 'Ordered edit operations for Blender'). The tool description adds no extra meaning beyond summarizing the overall action. Baseline 3 is appropriate since schema already documents parameters thoroughly.

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?

The description clearly states the action: 'Send STL-edit instructions to a Blender MCP bridge command for advanced model edits'. It identifies the specific verb 'send', the resource (STL instructions), and the context (Blender MCP bridge). This distinguishes it from sibling tools like specific edits (merge_vertices, center_model) or print tools.

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?

No guidance on when to use this tool versus alternatives. Siblings include specific STL editing tools (merge_vertices, center_model, lay_flat) and this is a general bridge for advanced edits, but the description does not explain scenarios or exclusion criteria.

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

camera_snapshotA

Capture a single JPEG frame from the printer's chamber camera. A1/P1 use TCP-on-6000; X1/P2S/H2 use RTSP via ffmpeg. Returns JPEG as base64; pass save_path to also write the bytes to disk.

ParametersJSON Schema

Name	Required	Description
`save_path`	No	Optional absolute path to write the JPEG to disk. If omitted, only the base64 payload is returned.
`timeout_ms`	No	Max ms to wait for a full frame (default 8000). Camera may take a few seconds on cold start.
`bambu_model`	No	Printer model. Used to route to the correct protocol or fail fast on unsupported models. Defaults to BAMBU_MODEL.
`experimental`	No	Deprecated and ignored. Earlier this flag let callers probe H2 series via the A1/P1 TCP-on-6000 path; live testing on an H2S confirmed H2 uses RTSP instead, so the flag has no effect now.
`ffmpeg_path`	No	Override path to the ffmpeg binary used by the RTSP path. Defaults to ffmpeg via $PATH. Required only for the RTSP transport (X1, P2S, H2 series).
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations to rely on, the description thoroughly discloses behavioral traits: the protocol differences (TCP vs RTSP), the default timeout of 8000ms, the cold start delay, and the deprecated/ignored experimental flag. This gives agents a complete understanding of what to expect.

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?

The description is extremely concise: two sentences that front-load the purpose and key behaviors. Every word adds value, with no filler or redundant information.

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?

Given the tool's complexity (multiple protocols, optional parameters) and rich schema descriptions, the description covers all essential aspects: what it does, protocol selection, output format, and key parameter behaviors like timeout. No output schema exists, but the return format is specified, so agents have sufficient context.

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 each parameter. The description adds some context (e.g., protocol routing, timeout default) but does not significantly enhance meaning beyond the schema definitions. Baseline 3 is appropriate.

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?

The description clearly states the tool captures a single JPEG frame from the printer's chamber camera, specifies the return format (base64), and differentiates between protocols for different printer models. This provides a specific verb and resource, making the tool's purpose unmistakable.

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 provides clear context on when to use the tool (to capture camera frames) and distinguishes protocol usage by model. It does not explicitly state when not to use it or provide alternatives, but among sibling tools there is no direct competitor, so the guidance is sufficient.

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

cancel_printB

Cancel the current print job on the Bambu Lab printer

ParametersJSON Schema

Name	Required	Description
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It states 'cancel' but does not clarify whether the job is removed from the queue, if it can be resumed, or if any confirmation is required. The lack of detail on side effects reduces transparency for an agent.

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?

The description is a single, concise sentence that efficiently communicates the purpose. No unnecessary words or repetitions.

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 simple cancel action with three optional parameters and no output schema, the description is minimally adequate. However, it lacks mention of prerequisites (e.g., an active job), irreversibility, or what happens to the job data, leaving some gaps for an agent.

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 100%, and each parameter has clear descriptions (hostname, serial, token) with defaults from environment. The description adds no extra meaning beyond the schema, meeting the baseline for high coverage.

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 clearly states the action 'Cancel' and the resource 'current print job on the Bambu Lab printer'. It distinguishes from sibling tools like pause_print and resume_print by implying finality, though it could explicitly note that it terminates rather than pauses.

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?

No guidance on when to use this tool versus alternatives like pause_print or start_print_job. Context signals indicate ample siblings, but the description does not specify that this is for stopping a running job irreversibly or that it should be used after confirming no further output is needed.

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

center_modelB

Translate the model so its geometric center is at the origin (0,0,0)

ParametersJSON Schema

Name	Required	Description	Default
`stl_path`	Yes	Path to the STL file

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It mentions translation but does not disclose whether the operation modifies the file in-place, returns a new file, or has other side effects.

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?

Single, front-loaded sentence with no redundancy. Could be slightly more structured, but effective for a simple operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks details about return values or file handling. With no output schema and no annotations, the agent is left guessing what happens post-operation.

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 100% for the single parameter (stl_path), but the description adds no extra meaning beyond the schema's 'Path to the STL file'. Baseline 3 is appropriate.

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?

The description clearly states the action ('translate') and resource ('model'), specifying the exact goal: geometric center at origin. It distinguishes from sibling tools like rotate_stl or scale_stl.

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?

No explicit when-to-use or when-not-to-use guidance. Sibling tools like lay_flat or merge_vertices are not mentioned, leaving the agent to infer context.

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

clear_hms_errorsB

Clear HMS or print error state on the Bambu Lab printer using the clean_print_error MQTT command.

ParametersJSON Schema

Name	Required	Description
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It mentions using an MQTT command but does not disclose side effects, required printer state, or whether it clears all errors or specific ones.

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?

One sentence, front-loaded with the verb 'clear', no wasted words.

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 simple tool with 3 optional parameters and no output schema, the description is minimal but functional. However, it lacks explanation of 'HMS errors', what clearing entails, or examples. Slightly below adequate.

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 100% with each parameter described. The description adds no extra meaning beyond the schema (host, serial, token with defaults). Baseline 3 is appropriate.

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?

The description clearly states the tool clears HMS or print error state on a Bambu Lab printer using a specific MQTT command. It distinguishes from sibling tools like cancel_print, pause_print, and resume_print.

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?

No guidance on when to use this tool versus alternatives. Given many printer-related siblings, the description lacks context about the appropriate scenario (e.g., after a print error) or conditions.

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

delete_printer_fileA

Delete a file from the Bambu Lab printer's SD card via FTPS. Destructive: requires confirm:true. Restricted to cache/, timelapse/, and logs/ directories. Path traversal segments (..) are rejected.

ParametersJSON Schema

Name	Required	Description
`filename`	Yes	File to delete. Bare names default to cache/<name>; pass a relative path like timelapse/foo.mp4 to target other allowed directories.
`confirm`	No	Must be true to actually delete. When false or omitted the call returns without sending an FTP request.
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: it deletes via FTPS, requires explicit confirmation (confirm:true), restricts directories, and blocks path traversal. This is comprehensive for a deletion tool.

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 concise sentences, each delivering key information: action, destructive guard, directory restriction, and path traversal check. No redundancy; well front-loaded.

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?

The description covers all essential aspects: operation, safety, constraints. A minor gap is lack of error handling info (e.g., file not found), but overall it is sufficiently complete for a file deletion tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds significant value: it clarifies default path for bare names ('cache/') and provides usage examples (e.g., 'timelapse/foo.mp4'). The confirm parameter behavior is clearly explained.

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?

The description clearly states the action ('delete a file'), the target ('Bambu Lab printer's SD card'), and the mechanism ('via FTPS'). It effectively distinguishes this tool from siblings like 'list_printer_files' and 'upload_file'.

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?

It provides important usage constraints: destructive nature requiring confirm:true, allowed directories (cache/, timelapse/, logs/), and rejection of path traversal. It does not explicitly compare with alternatives, but the constraints offer sufficient guidance for safe usage.

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

extend_stl_baseC

Extend the base of an STL file by a specified amount

ParametersJSON Schema

Name	Required	Description	Default
`stl_path`	Yes	Path to the STL file to modify
`extension_height`	Yes	Height in mm to extend the base by

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits like whether the file is modified in-place or a new file is created, but it does not. Side effects and requirements are absent.

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?

The description is a single, clear sentence with no unnecessary words. It effectively communicates the core purpose without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema and the presence of sibling STL manipulation tools, the description is too brief. It does not explain the output, error conditions, or how it differs from similar 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 coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's property descriptions; it merely restates the schema information.

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?

Description clearly states the action 'extend the base' on an STL file, which distinguishes it from sibling tools like scale_stl or rotate_stl. However, it is slightly vague on what 'extend the base' entails (e.g., adding material to the bottom vs. increasing thickness).

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?

No guidance on when to use this tool versus alternatives such as scale_stl or lay_flat. The description does not mention any prerequisites or contextual usage hints.

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

get_printer_filamentsB

Get the live AMS/external filament inventory from the printer over MQTT, including loaded/empty slot summary, resolved slicer profile paths, match confidence, and recommended load_filaments when the printer model is known.

ParametersJSON Schema

Name	Required	Description
`host`	No	Hostname or IP address of the printer (default: value from env)
`bambu_serial`	No	Serial number for the Bambu Lab printer (default: value from env)
`bambu_token`	No	Access token for the Bambu Lab printer (default: value from env)
`bambu_model`	No	Optional model hint used to resolve Bambu/Orca filament profile JSONs for each tray.
`nozzle_diameter`	No	Optional nozzle diameter used when resolving model-specific filament profile JSONs (default: 0.4).

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It mentions 'live... over MQTT' and lists outputs but does not explicitly state read-only nature, authentication needs, or error behaviors. It is adequate but not comprehensive.

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?

Single sentence efficiently covers purpose, method, and key outputs with no wasted words. Front-loaded with the main verb and resource.

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?

Given no output schema, the description lists the main return elements. It is fairly complete for a simple getter tool, though it could mention response format or limitations.

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 100% so baseline is 3. The description adds context linking bambu_model to 'recommended load_filaments', providing extra value beyond the schema descriptions.

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 clearly states the action (Get live inventory), the resource (AMS/external filament inventory from printer), and method (over MQTT). It lists specific included data but does not explicitly differentiate from sibling tools like 'reread_ams_rfid'.

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?

No explicit guidance on when to use this tool versus alternatives. The only hint is 'when the printer model is known' for recommended load_filaments, but no context for when not to use or prerequisites.

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

get_printer_statusC

Get the current status of the Bambu Lab printer

ParametersJSON Schema

Name	Required	Description
`host`	No	Hostname or IP address of the printer (default: value from env)
`bambu_serial`	No	Serial number for the Bambu Lab printer (default: value from env)
`bambu_token`	No	Access token for the Bambu Lab printer (default: value from env)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description must convey behavioral traits. It only states a simple read operation, but fails to disclose potential side effects (if any), error behavior (e.g., if printer is offline), or authentication requirements beyond the parameter defaults. This leaves the agent unaware of safety or failure modes.

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?

The description is a single concise sentence with no wasted words. However, it could benefit from slight expansion (e.g., a brief note on output format) without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and three optional parameters, the description should provide more context, such as the return format or typical use cases. Currently, it only states the basic action, leaving the agent uncertain about what data the tool returns and how to interpret results.

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?

The input schema has 100% coverage, describing each parameter with its purpose and default behavior. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate. The tool is simple and the schema is sufficient.

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 clearly states the action 'Get' and the resource 'current status of the Bambu Lab printer', making the tool's purpose apparent. It distinguishes itself from sibling tools like cancel_print or pause_print, but could be more specific about what aspects of status are retrieved (e.g., printing, idle, errors).

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?

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't suggest checking status before printing or mention related tools like get_printer_filaments or list_printer_files. The agent is left without context for selecting this tool.

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

get_slice_settingsA

Inspect slicer settings from a saved 3MF template or a JSON/config slicer profile without slicing anything.

ParametersJSON Schema

Name	Required	Description
`source_path`	No	Path to a 3MF template, extracted project_settings.config, or slicer profile JSON.
`template_name`	No	Optional named template from the local registry. If provided, resolves source_path automatically.
`template_dir`	No	Optional template directory override when resolving template_name.

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses the tool is read-only and does not modify anything. However, it does not describe the return format or any permissions needed, which would be helpful.

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?

The description is a single sentence, concise and front-loaded. Every word adds value and no redundant information is present.

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?

Given no output schema, the description should hint at the return type. It does not. The parameter details are fully covered by the schema, but the description lacks information about what the output looks like, which is needed for an inspection tool.

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 description adds no extra parameter meaning. The description does not elaborate on the parameters beyond what the schema already provides.

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?

The description clearly states the tool's purpose: inspect slicer settings from a 3MF template or JSON/config profile, and explicitly notes it does not slice. This distinguishes it from slicing tools among the siblings.

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?

The description implies usage for inspection only ('without slicing'), but does not explicitly state when to use this tool vs alternatives like 'slice_stl' or 'slice_with_template'. No when-not-to-use or alternative descriptions are provided.

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

get_stl_infoA

Get detailed information about an STL file (bounding box, face count, dimensions)

ParametersJSON Schema

Name	Required	Description	Default
`stl_path`	Yes	Path to the STL file to analyze

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are present, so the description carries the burden. It indicates a read-only operation by stating 'Get detailed information', but does not disclose error behavior, permissions needed, or any side effects. It adds some value by listing the exact information returned.

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?

The description is a single, focused sentence that immediately conveys purpose. No unnecessary words, well front-loaded.

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 a simple query tool with one parameter and no output schema, the description is nearly complete. It states what it does and what information it returns. Minor improvement could include noting it does not modify the file.

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% (the single parameter 'stl_path' is described). The tool description adds no additional meaning beyond the schema's 'Path to the STL file to analyze'. Baseline 3 is appropriate.

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?

The description clearly states the verb 'Get' and resource 'STL file', and specifies the kind of information (bounding box, face count, dimensions). It distinguishes from sibling tools that modify STL files, making it unambiguously a read-only information retrieval tool.

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?

The description implies usage when needing STL file details, but gives no explicit guidance on when to use this tool versus alternatives like scale_stl or slice_stl. No when-not or exclusion criteria are provided.

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

lay_flatA

Rotate the model so its largest flat face lies on the XY plane (Z=0)

ParametersJSON Schema

Name	Required	Description	Default
`stl_path`	Yes	Path to the STL file

TDQS

A3.5/5.0

Behavior3/5

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

The description explains the core action but lacks details on side effects (e.g., whether the file is modified in place), error handling for models without a flat face, or return value. With no annotations, more disclosure would be beneficial.

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?

Single, well-structured sentence that front-loads the action and outcome with no wasted words.

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?

Adequate for a simple tool but missing expected output description (e.g., returns path or modifies in place). Could mention prerequisites like presence of a flat face.

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?

Only one parameter with 100% schema coverage, but the description adds no extra meaning beyond the schema's 'Path to the STL file'. Baseline score of 3 is appropriate.

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?

The description clearly states the tool rotates the model so its largest flat face lies on the XY plane, using a specific verb and resource that distinguishes it from sibling tools like rotate_stl which require manual angles.

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?

No guidance on when to use this tool versus alternatives (e.g., rotate_stl, center_model). The description does not specify prerequisites or scenarios where this tool is appropriate.

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

list_3mf_plate_objectsA

List object IDs from a sliced 3MF plate. Use these IDs with skip_objects during a running print.

ParametersJSON Schema

Name	Required	Description	Default
`three_mf_path`	Yes	Path to a sliced 3MF/.gcode.3mf file
`plate_index`	No	0-based plate index to inspect (default: 0)

TDQS

A4.2/5.0

Behavior4/5

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

The description is transparent about the read-only nature of listing object IDs. No annotations are provided, so the description carries the burden and does so adequately.

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 sentences with no wasted words. The first sentence states the purpose, and the second gives actionable guidance. Excellent front-loading.

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?

The description is complete for a simple list operation, but lacking an output schema, it does not specify the format of the returned object IDs. However, the purpose and usage are clear enough.

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 100%, and the description does not add significant meaning beyond the schema's parameter descriptions. The additional context about skip_objects is usage guidance, not parameter semantics.

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?

The description clearly states the verb 'List' and the resource 'object IDs from a sliced 3MF plate', and distinguishes itself from siblings by specifying the use with skip_objects.

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 explicitly advises to use the IDs with skip_objects during a running print, providing clear context. It does not state when not to use it or list alternatives, but the usage is well-defined.

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

list_printer_filesC

List files stored on the Bambu Lab printer

ParametersJSON Schema

Name	Required	Description
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states 'list files'. It does not disclose whether the result includes file sizes, timestamps, or if pagination is used. For a read operation, more behavioral context would be expected.

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?

The description is a single, clear sentence. While it is concise, it could benefit from a bit more structure (e.g., specifying what information is returned).

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 simple list operation, the description is minimally adequate. However, given the lack of an output schema and the presence of many sibling tools, additional details about the returned file list (e.g., format, fields) would improve completeness.

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 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, which only indicate default values from environment variables.

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 clearly states the action ('list files') and the target ('stored on the Bambu Lab printer'). It distinguishes from sibling tools like 'delete_printer_file' or 'upload_file' which perform different operations on printer files.

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?

No guidance on when to use this tool versus alternatives such as 'get_printer_status' or 'slice_stl'. No mention of prerequisites, context, or when not to use it.

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

list_templatesB

List saved slicing templates from the local template registry directory.

ParametersJSON Schema

Name	Required	Description	Default
`template_dir`	No	Optional template directory override. Defaults to BAMBU_TEMPLATE_DIR or the server's configured local template registry.

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral aspects. It only says 'list' without describing return format, error handling, or side effects. No indication that this is a read-only operation or what happens if the directory is missing.

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?

The description is a single sentence with no extraneous information. Every word is necessary, and it is front-loaded with the action and resource.

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?

Given the simplicity of the tool (one optional param, no output schema), the description is minimally adequate. However, it lacks details on return values and edge cases, which could be added for completeness.

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 100% for the single parameter. The description does not add new information beyond the schema. Baseline 3 is appropriate as the schema already covers parameter details.

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?

The description clearly states the tool lists saved slicing templates from a specific local directory. The verb 'List' and resource 'saved slicing templates' are precise, distinguishing it from siblings like save_template and slice_with_template.

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?

No explicit guidance on when to use this tool or when to avoid it. No mention of prerequisites, default behavior, or alternatives. The description only states the source directory without context.

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

merge_verticesB

Merge vertices in an STL file closer than the specified tolerance

ParametersJSON Schema

Name	Required	Description	Default
`stl_path`	Yes	Path to the STL file
`tolerance`	No	Max distance to merge (mm, default: 0.01)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the file is modified in place, side effects, performance implications, or if the operation is destructive. The agent lacks crucial behavioral cues.

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?

The description is a single, front-loaded sentence with no wasted words. It is concise, though it could optionally provide a bit more context about the operation's effect without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and low complexity, the description should at least hint at return value or side effects (e.g., whether the file is overwritten). It lacks this context, making it incomplete for the agent to fully understand the tool's behavior.

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% (both parameters have descriptions). The description adds no additional meaning beyond what is in the schema, so a baseline of 3 is appropriate.

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?

The description clearly states the action ('Merge vertices in an STL file') and the condition ('closer than the specified tolerance'). It distinguishes from siblings like scale_stl, rotate_stl, etc., which perform different operations on STL files.

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?

No guidance on when to use this tool versus other STL tools, nor any prerequisites or exclusions. The description simply states what it does without context on alternatives like manual editing or other merge strategies.

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

pause_printA

Pause the current print job on the Bambu Lab printer (resumable via resume_print)

ParametersJSON Schema

Name	Required	Description
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A4/5.0

Behavior3/5

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

Without annotations, the description carries full burden. It discloses the action is non-destructive and resumable, but lacks details on permissions, timeouts, or state prerequisites.

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?

Single sentence, front-loaded with the verb, every word adds value. No fluff.

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?

Given low complexity and good schema, description is nearly complete. Only minor gap: it doesn't explicitly state that the printer must be printing.

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 100% with clear parameter descriptions. The description adds no additional parameter info, but baseline 3 is appropriate since schema already covers meaning.

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?

The description clearly states the verb 'Pause', the resource 'current print job on the Bambu Lab printer', and distinguishes this from sibling tools like cancel_print (destructive) and resume_print (reversal).

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?

It explicitly says when to use (pause current print job) and implies that resume_print is for resuming. However, it does not explicitly state when not to use or list all alternatives.

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

print_3mfB

Print a 3MF file on a Bambu Lab printer. Auto-slices if the 3MF has no gcode. IMPORTANT: bambu_model must be specified to ensure safe printer operation.

ParametersJSON Schema

Name	Required	Description
`three_mf_path`	Yes	Path to the 3MF file to print
`bambu_model`	Yes	REQUIRED: Bambu Lab printer model. Ask the user if not known. Using the wrong model can damage the printer.
`connection_mode`	No	Print path to use: lan_mqtt_ftps uses this MCP's direct local MQTT/FTPS path; bambu_network uses the restored FULU BambuNetwork bridge.
`connection_type`	No	BambuNetwork connection type when connection_mode is bambu_network; cloud uses restored internet printing, lan uses local bridge printing.
`bambu_network_method`	No	FULU print method when connection_mode is bambu_network; defaults to start_print for cloud and start_local_print for lan.
`dev_id`	No	Bambu device id for FULU BambuNetwork printing; defaults to BAMBU_DEV_ID or BAMBU_SERIAL.
`dev_ip`	No	Printer IP address for FULU BambuNetwork LAN/local print methods; defaults to host when provided.
`bridge_command`	No	Override command for the FULU bridge host or macOS/WSL wrapper; defaults to BAMBU_NETWORK_BRIDGE_COMMAND.
`bambu_network_config_dir`	No	Config/log directory used by the FULU BambuNetwork agent.
`country_code`	No	BambuNetwork country code, such as US, used by the FULU bridge agent.
`user_info`	No	Optional BambuNetwork user_info JSON string passed to net.change_user for the FULU bridge.
`bed_type`	No	Bed plate type currently installed (default: textured_plate)
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)
`plate_index`	No	Zero-based plate index to print from the sliced 3MF (default: 0)
`slicer_type`	No	Slicer to use only if auto-slicing an unsliced 3MF. Bambu-compatible slicer aliases such as fulu-orca and orca-studio are accepted.
`slicer_path`	No	Path to the slicer executable for auto-slicing (default: value from env or a platform default)
`use_ams`	No	Whether to use the AMS (default: auto-detect from 3MF)
`ams_mapping`	No	Project-level AMS mapping array. Position = project filament index, value = absolute AMS tray (0-3=AMS 0, 4-7=AMS 1, 8-11=AMS 2, 128+=AMS-HT, 254=external, -1=unused). Prefer ams_slots unless you know the project-level layout.
`ams_slots`	No	Preferred AMS input: one absolute tray index per USED filament in plate order, e.g. [1] for a single-filament print pulling from AMS 0 slot 1. Expanded to project-level ams_mapping automatically from the 3MF's plate_N.json and gcode header.
`auto_match_ams`	No	When true, match the sliced 3MF's tray_info_idx requirements against live AMS inventory and use the resulting ams_slots. Ignored when ams_mapping or ams_slots is provided.
`bed_leveling`	No	Enable auto bed leveling (default: true)
`flow_calibration`	No	Enable flow calibration (default: true)
`vibration_calibration`	No	Enable vibration calibration (default: true)
`timelapse`	No	Enable timelapse recording (default: false)
`slicer_profile`	No	Path to the slicer profile/config file for auto-slicing (optional).
`template_3mf_path`	No	Optional template 3MF whose embedded Bambu slicer settings should be reused when auto-slicing this print job.
`template_name`	No	Optional named template from the local registry. Resolves to template_3mf_path automatically.
`template_dir`	No	Optional template directory override when resolving template_name.
`nozzle_diameter`	No	Nozzle diameter in mm for auto-slicing (default: 0.4)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must carry full behavioral disclosure. It mentions auto-slicing and the importance of bambu_model, but omits side effects, error handling, prerequisites, and details about network modes. Important behavioral traits are missing.

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?

The description is concise (two sentences) and front-loaded with purpose. However, it could be structured to include more behavioral notes or a brief overview of connection modes without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (31 parameters, no output schema), the description is far too minimal. It does not explain what the tool returns, prerequisites, or how connection modes differ. Significant gaps remain.

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 100%, so parameter descriptions in the schema already document each parameter. The description only emphasizes bambu_model, adding minimal value. Baseline 3 is appropriate.

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 clearly states the tool prints a 3MF file on a Bambu Lab printer, and mentions auto-slicing. However, it does not differentiate from sibling tools like 'print_3mf_bambu_network', which appears to be a variant for a specific network mode.

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?

The description emphasizes that bambu_model is required for safety, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., print_3mf_bambu_network). Usage is implied but lacks exclusions.

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

print_3mf_bambu_networkA

Print a 3MF through FULU OrcaSlicer-bambulab's restored BambuNetwork path instead of the MCP LAN MQTT/FTPS path.

ParametersJSON Schema

Name	Required	Description
`three_mf_path`	Yes	Path to the 3MF file to print; unsliced 3MFs are auto-sliced before sending.
`bambu_model`	Yes	REQUIRED: Bambu Lab printer model. Ask the user if not known. Using the wrong model can damage the printer.
`connection_type`	No	BambuNetwork connection type to put in FULU PrintParams; cloud uses restored internet printing, lan uses local bridge printing.
`bambu_network_method`	No	FULU print method to invoke; defaults to start_print for cloud and start_local_print for lan.
`dev_id`	No	Bambu device id used by BambuNetwork; defaults to BAMBU_DEV_ID or BAMBU_SERIAL.
`dev_ip`	No	Printer IP address for LAN/local bridge methods; defaults to host when provided.
`host`	No	Printer host or IP address, used as dev_ip for LAN/local bridge methods.
`bambu_serial`	No	Fallback Bambu device id when dev_id is not supplied.
`bambu_token`	No	Printer access code/password for LAN/local bridge methods.
`username`	No	Printer username for LAN/local bridge methods; defaults to bblp.
`password`	No	Printer password/access code override for LAN/local bridge methods.
`bed_type`	No	Bed plate type currently installed (default: textured_plate).
`plate_index`	No	Zero-based plate index to print from the sliced 3MF; converted to FULU's one-based PrintParams plate_index.
`project_name`	No	Optional project name sent in FULU PrintParams; defaults to the 3MF filename without extension.
`preset_name`	No	Optional preset name sent in FULU PrintParams; defaults to project plus one-based plate index.
`task_name`	No	Optional BambuNetwork task name; defaults to the project name.
`config_filename`	No	Optional config 3MF path for cloud print; defaults to the same 3MF path.
`bridge_command`	No	Override command for the FULU bridge host or macOS/WSL wrapper; defaults to BAMBU_NETWORK_BRIDGE_COMMAND.
`bambu_network_config_dir`	No	Config/log directory used by the BambuNetwork agent; defaults to BAMBU_NETWORK_CONFIG_DIR or a user config directory.
`country_code`	No	BambuNetwork country code, such as US, used by the agent during startup.
`user_info`	No	Optional BambuNetwork user_info JSON string to pass to net.change_user after the agent starts.
`timeout_ms`	No	Bridge request timeout in milliseconds.
`slicer_type`	No	Slicer to use only if auto-slicing an unsliced 3MF; use orcaslicer-bambulab for FULU's fork.
`slicer_path`	No	Path to the slicer executable for auto-slicing; defaults to value from env or a platform default.
`slicer_profile`	No	Path to an optional slicer profile/config file for auto-slicing.
`nozzle_diameter`	No	Nozzle diameter in mm for auto-slicing (default: 0.4).
`use_ams`	No	Whether to use the AMS; defaults to auto-detect from the 3MF mapping.
`ams_mapping`	No	AMS slot mapping array used by both local MCP printing and FULU PrintParams.
`ams_slots`	No	Per-used-filament AMS slot list, matching the local LAN print path.
`ams_mapping_bridge`	No	Raw JSON string override for FULU PrintParams ams_mapping when the automatic array is not enough.
`ams_mapping2`	No	Raw JSON string for FULU PrintParams ams_mapping2, matching OrcaSlicer-bambulab's v1 AMS mapping field.
`ams_mapping_info`	No	Raw JSON string for FULU PrintParams ams_mapping_info, matching OrcaSlicer-bambulab's detailed AMS mapping field.
`nozzle_mapping`	No	Raw JSON string for FULU PrintParams nozzle_mapping.
`nozzles_info`	No	Raw JSON string for FULU PrintParams nozzles_info.
`bed_leveling`	No	Enable auto bed leveling in FULU PrintParams (default: true).
`flow_calibration`	No	Enable flow calibration in FULU PrintParams (default: true).
`vibration_calibration`	No	Enable vibration calibration in FULU PrintParams (default: true).
`layer_inspect`	No	Enable first-layer inspection where supported (default: false for BambuNetwork bridge).
`timelapse`	No	Enable timelapse recording in FULU PrintParams (default: false).
`use_ssl_for_ftp`	No	Whether FULU local print should use SSL for FTP (default: true).
`use_ssl_for_mqtt`	No	Whether FULU local print should use SSL for MQTT (default: true).
`external_change_assist`	No	Enable FULU PrintParams task_ext_change_assist for external filament change assistance.
`try_emmc_print`	No	Enable FULU PrintParams try_emmc_print for printers that support internal storage printing.
`extra_options`	No	Raw JSON string or text for FULU PrintParams extra_options.
`client_job_id`	No	Optional client job id sent to the bridge; defaults to the current timestamp.

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the network path change but does not reveal important behaviors: that it initiates a print job (mutation), potential errors, required permissions, or expected latency. The detailed parameter descriptions mildly compensate, but the tool-level description is insufficient.

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?

The description is a single, front-loaded sentence (16 words) with zero wasted words. It perfectly achieves conciseness and structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the rich parameter descriptions, the tool-level description fails to provide context about the overall operation, such as what happens after the print is sent (e.g., success/failure indicators, return status), error conditions, or integration with FULU system. For a complex print tool with 45 parameters and no output schema, this is a significant gap.

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 baseline is 3. The tool description itself adds no parameter information; all semantics are in the schema. This meets the baseline but does not exceed it.

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?

The description clearly states the action (Print), the resource (3MF), and the specific method (through FULU OrcaSlicer-bambulab's restored BambuNetwork path). It explicitly distinguishes this tool from its sibling 'print_3mf' by contrasting the network path, making the purpose unambiguous.

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 provides clear guidance on when to use this tool versus alternatives by specifying 'instead of the MCP LAN MQTT/FTPS path.' However, it does not explicitly state prerequisites or scenarios where this tool should be avoided, such as when BambuNetwork is unavailable.

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

print_collar_charmA

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.

ParametersJSON Schema

Name	Required	Description
`source_path`	No	Path to a prepared collar charm .3mf project or sliced 3MF.
`template_name`	No	Named collar charm template from the local registry. Resolves source_path automatically.
`template_dir`	No	Optional template directory override when resolving template_name.
`bambu_model`	No	REQUIRED: Bambu Lab printer model. H2D and H2S are the primary intended paths.
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)
`bed_type`	No	Bed plate type currently installed (default: textured_plate)
`bed_leveling`	No	Enable auto bed leveling (default: true)
`flow_calibration`	No	Enable flow calibration (default: true)
`vibration_calibration`	No	Enable vibration calibration (default: true)
`timelapse`	No	Enable timelapse recording (default: false)
`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)

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It specifies the fixed tray policy with exact color and slot assignments, which is helpful. However, it lacks details on prerequisites (e.g., project must be 'prepared'), potential side effects, or error handling. The description adds some value but not comprehensive behavioral context.

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?

The description is a single sentence that conveys the core purpose and a key behavioral detail (tray policy). It is concise, front-loaded, and contains no redundant information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 14 parameters and no output schema, the description is extremely brief. It does not explain how parameters affect the process, what the tool returns, or prerequisites beyond 'prepared project'. For a complex tool, this is insufficient for an agent to invoke correctly without external knowledge.

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 100%, so the baseline is 3. The description does not add any parameter-specific information beyond what the schema already provides. It does not explain how parameters like 'bambu_model' or 'slicer_profile' relate to the collar charm process, so it meets but does not exceed expectations.

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?

The description clearly states the tool prints a 'prepared two-part dog collar charm project' with a specific fixed tray policy, distinguishing it from generic print tools like print_3mf. The verb 'print' and resource 'collar charm project' are specific, and the sibling list includes many print-related tools, making the unique purpose evident.

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?

The description implies usage for collar charm projects but does not explicitly state when to use this tool versus alternatives (e.g., print_3mf for general projects). No exclusion criteria or context for when not to use it are provided, leaving the agent to infer applicability.

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

reread_ams_rfidA

Trigger a Bambu AMS RFID re-read for one AMS slot. This can move AMS filament; use only when the printer is idle and unloaded.

ParametersJSON Schema

Name	Required	Description
`ams_id`	Yes	AMS unit index from 0 to 3
`slot_id`	Yes	Slot index within that AMS, from 0 to 3
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that the tool 'can move AMS filament,' which is a critical behavioral trait beyond a simple read. This warns the agent about physical movement, aiding safe invocation.

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 concise sentences: first states purpose, second adds crucial usage condition. No redundant words; every sentence earns its place. Front-loaded with the primary action.

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?

Given 5 parameters, no output schema, and moderate complexity, the description covers the essential purpose and a key safety condition. It lacks details on return value or what happens after triggering, but such tools often act as fire-and-forget commands, making the description sufficient.

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 100%, with all 5 parameters described clearly. The description adds no extra semantic meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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?

Description clearly states verb ('Trigger a ... re-read') and specific resource ('one AMS slot'). It distinguishes from sibling tools like get_printer_filaments or set_ams_drying by focusing on RFID re-reading, and includes the notable side effect of moving filament.

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?

Explicitly states condition: 'use only when the printer is idle and unloaded.' This provides clear guidance on when to invoke. No explicit alternatives mentioned, but the context is sufficient.

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

resolve_3mf_ams_slotsA

Inspect a sliced 3MF and match its tray_info_idx filament requirements against the live AMS inventory. Does not upload or start a print.

ParametersJSON Schema

Name	Required	Description
`three_mf_path`	Yes	Path to a sliced 3MF/.gcode.3mf file
`plate_index`	No	0-based plate index to inspect (default: 0)
`bambu_model`	No	Optional model hint used to resolve Bambu/Orca filament profile JSONs for each tray.
`nozzle_diameter`	No	Nozzle diameter in mm (default: 0.4)
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It states it inspects and matches, with no upload or print start, but does not disclose if it modifies anything, requires read-only access, or details behavior on mismatch.

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 sentences, concise, front-loaded with verb 'Inspect'. Every sentence adds value with no wasted words.

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?

No output schema exists, but the description does not mention return values, error conditions, or response format. For a tool with 7 parameters, it is adequate but could be more complete.

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 100%, so baseline is 3. The description adds context by linking purpose to filament matching, but does not elaborate on parameter relationships or usage specifics beyond schema.

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?

Clearly states it inspects a 3MF file and matches filament requirements against AMS inventory. Explicitly distinguishes from print tools by stating 'Does not upload or start a print.'

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?

Implies usage for inspection only by stating it does not upload or start a print, but lacks explicit guidance on when to use vs alternatives (e.g., print_3mf, reread_ams_rfid).

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

resume_printB

Resume a paused print job on the Bambu Lab printer

ParametersJSON Schema

Name	Required	Description
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

B3.3/5.0

Behavior2/5

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

Annotations are absent, and the description does not disclose behavioral traits such as whether the print must be paused, what happens if it's already printing, or any side effects. The single sentence offers minimal transparency.

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?

The description is a single concise sentence with no wasted words. It front-loads the action and resource, but could be slightly more informative without losing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is incomplete. It does not explain expected return values (e.g., success message, new status) nor provide context for differentiating among many sibling 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%, so the parameters are fully documented in the schema. The description adds no extra meaning beyond what the schema provides, resulting in a baseline score.

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?

The description uses a specific verb ('Resume'), clearly identifies the resource ('paused print job'), and specifies the brand/context ('Bambu Lab printer'). It distinguishes well from sibling tools like 'pause_print', 'cancel_print', and 'start_print_job'.

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?

No explicit guidance on when to use or not use this tool. It does not mention that the print must be paused beforehand, nor does it contrast with alternatives like 'cancel_print' or 'start_print_job'. The usage is only implied from the verb.

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

rotate_stlB

Rotate an STL file by specified angles (degrees)

ParametersJSON Schema

Name	Required	Description
`stl_path`	Yes	Path to the STL file to rotate
`angle_x`	No	Rotation angle for X axis in degrees (default: 0)
`angle_y`	No	Rotation angle for Y axis in degrees (default: 0)
`angle_z`	No	Rotation angle for Z axis in degrees (default: 0)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description lacks details about side effects (e.g., overwrites the file, creates a new file), required permissions, or output format. Only the unit (degrees) is mentioned.

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?

The description is a single, front-loaded sentence that is concise and to the point, with no unnecessary words.

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?

The description is adequate for a simple tool with 4 well-documented parameters, but fails to explain whether the rotation modifies the file in-place or outputs a new file, which is relevant context.

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?

All parameters are documented in the schema with descriptions. The tool description adds no additional meaning beyond the schema, so it meets the baseline for high schema coverage.

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?

The description clearly states the action (rotate) and the resource (STL file) with specific angles, distinguishing it from sibling tools like scale_stl or extend_stl_base.

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?

No guidance on when to use this tool versus alternatives like blender_mcp_edit_model or when not to use it. No context about prerequisites or preferred scenarios.

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

save_templateB

Copy a 3MF, JSON, or config file into the local template registry and register it under a template name.

ParametersJSON Schema

Name	Required	Description
`source_path`	Yes	Path to a local .3mf, .json, or .config file to save into the template registry.
`template_name`	No	Optional template name. Defaults to the source filename without extension.
`template_dir`	No	Optional template directory override. Defaults to BAMBU_TEMPLATE_DIR or the server's configured local template registry.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It omits important details such as whether existing templates are overwritten, required permissions, or potential side effects. The description is minimal.

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?

A single concise sentence that immediately conveys the tool's purpose. No unnecessary words or redundancy.

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?

Given no output schema and no annotations, the description is moderately complete but lacks information about the return value or success/failure behavior. It sufficiently explains the operation for a simple file copy and registration.

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 description adds little beyond what the schema already provides. It repeats file types but does not clarify default behavior or constraints not already in the schema.

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?

The description clearly states the action ('Copy and register'), the resource (3MF, JSON, or config file), and the target (local template registry under a template name). It effectively distinguishes from sibling tools like list_templates or slice_with_template.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., upload_file). It does not mention prerequisites, exclusions, or context where other tools are preferred.

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

scale_stlB

Scale an STL file by specified factors

ParametersJSON Schema

Name	Required	Description
`stl_path`	Yes	Path to the STL file to scale
`scale_x`	No	Scale factor for X axis (default: 1.0)
`scale_y`	No	Scale factor for Y axis (default: 1.0)
`scale_z`	No	Scale factor for Z axis (default: 1.0)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It fails to mention whether the file is modified in-place, if a new file is created, or any side effects like overwriting. This is a significant gap for a transformation tool.

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?

The description is a single, efficient sentence with no wasted words. However, it could include more useful details without becoming verbose, such as the effect of uniform scaling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is incomplete. It lacks details on return values, error conditions, and the overall process (e.g., whether scaling is uniform or per-axis). This leaves the agent underinformed.

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 100% and all parameters have descriptions defining their roles (scale factors with defaults, file path). The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.

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?

The description 'Scale an STL file by specified factors' clearly states the verb (scale), resource (STL file), and scope (by factors). It effectively differentiates from sibling tools like rotate_stl and extend_stl_base.

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?

The description implies usage when scaling is needed, but provides no explicit guidance on when to use this tool over alternatives or what conditions warrant scaling. No exclusions or alternative tool names mentioned.

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

set_airduct_modeA

Set H2/P2 airduct mode to cooling or heating.

ParametersJSON Schema

Name	Required	Description
`mode`	Yes	Airduct mode to apply
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A3.6/5.0

Behavior3/5

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

No annotations exist, so the description must disclose behavioral traits. It does not mention any side effects, prerequisites, or limitations (e.g., whether the mode change is immediate or reversible). This is a basic level of transparency.

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?

The description is a single sentence with no wasted words. It is front-loaded and to the point, though slightly ambiguous in phrasing ('Set H2/P2 airduct mode' could be read as a noun phrase but remains clear).

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?

Given no output schema, the description covers the basic purpose but omits important context: the tool is specific to H2/P2 printers. A more complete description would clarify the target printer type and any prerequisites.

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?

The input schema has 100% description coverage, so the description adds no extra meaning beyond the schema. The schema already defines the mode enum and provides defaults for host, serial, and token.

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?

The description clearly states the action ('Set') and the resource ('airduct mode') with specific values ('cooling or heating') and target hardware ('H2/P2'). It distinguishes itself from sibling tools like set_temperature or set_fan_speed.

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?

No guidance is provided on when to use this tool versus alternatives or when not to use it. The description is minimal and does not differentiate usage from sibling tools like set_ams_drying.

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

set_ams_dryingA

Start or stop the AMS filament drying cycle. Available on AMS units with heating capability (AMS Pro / AMS-HT). Sends an ams_control MQTT command to the printer.

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Whether to start or stop the drying cycle
`ams_id`	Yes	AMS unit index from 0 to 3
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description must disclose behavior. It mentions 'Sends an ams_control MQTT command', which adds transparency about the underlying mechanism. However, it does not discuss potential delays, success/failure feedback, or side effects, leaving gaps for a critical control action.

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 sentences cover purpose, compatibility, and mechanism with no redundant words. The description is efficiently front-loaded with the core action.

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 simple start/stop command, the description provides adequate purpose and compatibility. However, without an output schema, it lacks detail on what the agent should expect after invocation (e.g., confirmation, status update). This is a modest completeness gap given the tool's low 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?

The input schema already describes all five parameters (100% coverage), including the action enum and ams_id range. The description adds no parameter-specific context beyond the implementation note, so it does not significantly augment the schema meaning. Baseline of 3 is appropriate.

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?

The description clearly states 'Start or stop the AMS filament drying cycle', using a specific verb for the action and identifying the resource. It distinguishes this tool from siblings, as none other mention drying cycles.

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 specifies that the tool is 'Available on AMS units with heating capability (AMS Pro / AMS-HT)', providing clear context for when to use it. It does not explicitly state when not to use it or mention alternatives, but the compatibility note is sufficient for correct selection.

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

set_fan_speedA

Set a Bambu printer fan speed percentage using the printer's MQTT fan command

ParametersJSON Schema

Name	Required	Description
`fan`	Yes	Fan to control: part, auxiliary, chamber, 1, 2, or 3
`speed`	Yes	Fan speed percentage from 0 to 100
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description must disclose behavior. It mentions MQTT but omits important traits: success/failure feedback, error handling, whether the command is synchronous, or if the printer must be connected. Insufficient for a safe agent use.

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?

Single sentence, 14 words, perfectly concise. Front-loads the core action and method. No redundant or filler content.

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?

Despite no annotations and no output schema, the description is reasonably complete for a simple set operation. However, it lacks context on error handling, async behavior, and dependency on printer connection, which limits its completeness.

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 baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions. No additional context on valid ranges, defaults, or usage hints.

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?

Clearly states the action (set), resource (Bambu printer fan speed percentage), and method (MQTT fan command). Distinguishes effectively from sibling tools like set_airduct_mode or set_temperature.

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?

Provides no explicit guidance on when to use this tool vs alternatives. While the name and context imply use for fan speed control, it does not mention prerequisites or when not to use it.

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

set_lightA

Set a Bambu printer light node mode using the printer's MQTT LED command

ParametersJSON Schema

Name	Required	Description
`light`	Yes	Light node to control, for example chamber_light
`mode`	Yes	Light mode to apply
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided. The description adds the MQTT mechanism and implies state mutation, but does not disclose side effects, required permissions, rate limits, or safety implications. More behavioral context would be beneficial.

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?

A single sentence that is front-loaded with the verb and resource. No redundant or unnecessary words, making it highly concise and to the point.

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 a simple mutation tool with five parameters and no output schema, the description covers the basic functionality. Minor gaps include not specifying default behavior for optional parameters or failure results, but overall sufficient.

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 100% with descriptions for all five parameters. The description adds minimal extra meaning beyond the schema, such as the specific light node example and the enum values, but does not significantly enrich parameter understanding.

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?

The description clearly states the verb 'Set', the resource 'Bambu printer light node mode', and the mechanism 'using the printer's MQTT LED command'. It effectively distinguishes from siblings like set_airduct_mode or set_fan_speed.

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?

The description implies usage for controlling printer lights, but lacks explicit guidance on when to use versus alternatives, prerequisites, or exclusions. No when-not-to-use or alternative tool mentions.

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

set_print_speedB

Set the active print speed mode: silent, standard, sport, or ludicrous.

ParametersJSON Schema

Name	Required	Description
`mode`	Yes	Speed mode to apply: silent/1, standard/2, sport/3, or ludicrous/4
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description bears the full burden of disclosing behavior. It only states the function without revealing any side effects (e.g., whether the change is instantaneous, if it affects ongoing prints, if authentication is required). The description is too terse to convey important behavioral traits for an agent invoking the tool.

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?

The description is a single, well-structured sentence that immediately conveys the tool's purpose and lists all options. It wastes no words and is easy to parse.

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 simple setter tool with no output schema and no annotations, the description is moderately complete. It correctly identifies the parameter and values but lacks context about prerequisites or consequences (e.g., does this require the printer to be online? Can it be called mid-print?). Given the complexity (4 params, but only one is core), it is adequate but not comprehensive.

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 100% with each parameter described. The description adds marginal value by listing the symbolic mode names, but the schema already includes those as enum values. The 'host', 'bambu_serial', and 'bambu_token' parameters' meanings are not enhanced by the description. Baseline 3 is appropriate since 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?

The description clearly states the action ('Set') and the resource ('active print speed mode'), and enumerates the exact possible values ('silent, standard, sport, or ludicrous'). This is sufficiently specific to distinguish from other set_* sibling tools which target different parameters (airduct, fan, light, temperature).

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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., printer must be connected or in certain state), nor does it indicate when not to use it. Sibling tools like 'pause_print', 'resume_print' suggest usage context, but the description itself lacks any usage direction.

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

set_temperatureB

Set the temperature of a printer component (bed, nozzle)

ParametersJSON Schema

Name	Required	Description
`component`	Yes	Component to heat: bed, nozzle, or extruder
`temperature`	Yes	Target temperature in °C
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; description only states the action without disclosing behavior (e.g., synchronous vs asynchronous heating, safety implications, authentication needs).

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?

Single sentence, no redundant phrasing; however, could include more detail without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool modifies hardware state but lacks information about return values, errors, or dependencies (e.g., printer connectivity). Output schema not provided, but description could compensate.

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 covers all parameters with descriptions (100% coverage); description adds minimal extra meaning beyond listing component types already in schema.

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?

Description clearly states the action (set), resource (temperature of printer component), and examples (bed, nozzle), distinguishing it from other sibling tools like set_fan_speed or set_light.

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?

No guidance on when to use this tool versus others; no mention of prerequisites or contexts where this is appropriate.

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

skip_objectsA

Skip specific object IDs during a running multi-object print using the printer's MQTT skip_objects command

ParametersJSON Schema

Name	Required	Description
`object_ids`	Yes	Object IDs to skip. Use list_3mf_plate_objects on the sliced 3MF to find IDs.
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It mentions using MQTT (network) but does not disclose reversibility, permission requirements, or error handling. Minimal behavioral disclosure.

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?

The description is a single concise sentence with no unnecessary words. It is front-loaded but could be slightly more structured with separate sentences for different aspects.

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?

Given no output schema and no annotations, the description provides the core purpose and parameter guidance, but lacks information on return values, errors, or side effects, making it minimally adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters, and the description adds value for object_ids by referencing list_3mf_plate_objects. The host, bambu_serial, and bambu_token defaults are already in the schema, so limited added meaning.

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?

The description clearly states the action (skip), the resource (object IDs during a running multi-object print), and the method (MQTT command). It distinguishes from sibling tools like pause_print or cancel_print.

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 specifies the context (during a running multi-object print) and guides the agent to use list_3mf_plate_objects to find object IDs. It does not explicitly state when not to use, but the context is sufficient.

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

slice_stlB

Slice an STL or 3MF file using a slicer to generate printable G-code or sliced 3MF. IMPORTANT: bambu_model must be specified to ensure the slicer generates safe G-code for the correct printer.

ParametersJSON Schema

Name	Required	Description
`stl_path`	Yes	Path to the STL or 3MF file to slice
`bambu_model`	Yes	REQUIRED: Bambu Lab printer model. Ask the user if not known. Using the wrong model can damage the printer.
`slicer_type`	No	Type of slicer to use. Bambu-compatible choices (bambustudio, orcaslicer, orcaslicer-bambulab) export sliced 3MF; aliases such as fulu-orca and orca-studio are accepted.
`slicer_path`	No	Path to the slicer executable (default: value from env)
`slicer_profile`	No	Path to the slicer profile/config file (optional, overrides bambu_model preset)
`template_3mf_path`	No	Optional template 3MF whose embedded Bambu slicer settings should be reused when slicing a new STL or 3MF.
`template_name`	No	Optional named template from the local registry. Resolves to template_3mf_path automatically.
`template_dir`	No	Optional template directory override when resolving template_name.
`nozzle_diameter`	No	Nozzle diameter in mm (default: 0.4)
`bed_type`	No	Bed plate type for slicing (default: textured_plate). SuperTack is accepted only for pre-sliced print jobs until the BambuStudio CLI identifier is verified.
`use_printer_filaments`	No	When true, and no explicit slicer profile or load_filaments override is provided, use the printer's current or first loaded AMS filament as the slicer filament profile. Template 3MF process settings can still be used at the same time.
`uptodate`	No	Refresh 3MF preset configs to match the latest BambuStudio version. Use when slicing downloaded or older 3MF files to prevent stale-config failures.
`repetitions`	No	Print N identical copies of the model. Each copy gets its own plate placement. Example: 3 prints three copies.
`orient`	No	Auto-orient the model for optimal printability (minimize supports, maximize bed adhesion). Recommended for raw STL imports that lack a pre-set orientation.
`arrange`	No	Auto-arrange all objects on the build plate with optimal spacing. Recommended when importing STLs or adding multiple objects. Set false to preserve existing plate layout.
`ensure_on_bed`	No	Detect models floating above the bed and lower them onto the build surface. Safety net for imported models with incorrect Z origins.
`clone_objects`	No	Duplicate specific objects on the plate. Comma-separated clone counts per object index, e.g. '1,3,1,10' clones object 0 once, object 1 three times, etc.
`skip_objects`	No	Skip specific objects during slicing by index. Comma-separated, e.g. '3,5,10'. Useful for multi-object 3MFs where you only want to print some parts.
`load_filaments`	No	Override filament profiles. Semicolon-separated paths to filament JSON configs, e.g. 'pla_basic.json;petg_cf.json'.
`filament_profile`	No	Compatibility alias for load_filaments. Semicolon-separated Orca/Bambu filament profile JSON paths.
`load_filament_ids`	No	Map filaments to objects/parts. Comma-separated IDs matching load_filaments order, e.g. '1,2,3,1' assigns filament 1 to objects 0 and 3.
`enable_timelapse`	No	Insert timelapse parking moves into gcode. The toolhead parks at a fixed position each layer for camera capture. Adds ~10% print time.
`allow_mix_temp`	No	Allow filaments with different temperature requirements on the same plate. Required for multi-material prints mixing e.g. PLA and PETG.
`scale`	No	Uniform scale factor applied to all axes. 1.0 = original size, 2.0 = double, 0.5 = half. Applied before slicing.
`rotate`	No	Rotate the model around the Z-axis (vertical) by this many degrees before slicing. Positive = counterclockwise when viewed from above.
`rotate_x`	No	Rotate the model around the X-axis by this many degrees before slicing. Useful for reorienting prints for better layer adhesion.
`rotate_y`	No	Rotate the model around the Y-axis by this many degrees before slicing. Useful for reorienting prints for better layer adhesion.
`min_save`	No	Write a smaller output 3MF by omitting non-essential metadata. Reduces file size for faster FTP upload to the printer.
`skip_modified_gcodes`	No	Strip custom start/end gcodes embedded in the 3MF. Recommended for downloaded 3MFs since custom gcodes from other users' profiles may be unsafe for your printer.
`slice_plate`	No	Which plate index to slice. 0 = all plates (default). Use 1, 2, etc. to slice only a specific plate in multi-plate 3MF projects.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose side effects (e.g., file creation), performance, error conditions, or whether it modifies input files. For a tool with 30 parameters, this is insufficient.

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?

The description is two sentences, efficient in length, but the bolded 'IMPORTANT' is slightly noisy. It could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity (30 parameters), no output schema, and multiple sibling tools, the description is very incomplete. It does not explain return values, error handling, or how the output is used. A more complete description would include behavior beyond basic action.

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 parameters. The description adds no extra meaning beyond highlighting bambu_model, which is already required. Baseline 3 is appropriate.

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 clearly states the verb ('slice'), resource ('STL or 3MF file'), and output ('printable G-code or sliced 3MF'). It also highlights a critical prerequisite (bambu_model). However, it does not differentiate from sibling tools like slice_with_template.

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?

The description emphasizes that bambu_model must be specified for safety, which is a usage guideline. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., slice_with_template) or when not to use it.

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

slice_with_templateB

Slice an STL or 3MF using a named template from the local registry. This is a higher-level wrapper around slice_stl for template-based workflows.

ParametersJSON Schema

Name	Required	Description
`stl_path`	Yes	Path to the STL or 3MF file to slice
`template_name`	Yes	Named template from the local registry.
`template_dir`	No	Optional template directory override when resolving template_name.
`bambu_model`	Yes	REQUIRED: Bambu Lab printer model. Ask the user if not known. Using the wrong model can damage the printer.
`slicer_type`	No	Type of slicer to use. Bambu-compatible choices (bambustudio, orcaslicer, orcaslicer-bambulab) export sliced 3MF; aliases such as fulu-orca and orca-studio are accepted.
`slicer_path`	No	Path to the slicer executable (default: value from env)
`slicer_profile`	No	Explicit slicer profile/config file. Overrides the named template only when provided in the tool call.
`nozzle_diameter`	No	Nozzle diameter in mm (default: 0.4)
`bed_type`	No	Bed plate type for slicing (default: textured_plate). SuperTack is accepted only for pre-sliced print jobs until the BambuStudio CLI identifier is verified.
`use_printer_filaments`	No	When true, and no explicit slicer profile or load_filaments override is provided, use the printer's current or first loaded AMS filament as the slicer filament profile.
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)
`load_filaments`	No	Override filament profiles. Semicolon-separated paths to filament JSON configs.
`load_filament_ids`	No	Optional filament-to-object mapping string.
`ensure_on_bed`	No	Lift floating models onto the bed.
`arrange`	No	Auto-arrange objects on the build plate.
`orient`	No	Auto-orient model for optimal printability.
`repetitions`	No	Number of copies to print.
`scale`	No	Uniform scale factor.
`rotate`	No	Z-axis rotation in degrees.
`rotate_x`	No	X-axis rotation in degrees.
`rotate_y`	No	Y-axis rotation in degrees.
`min_save`	No	Produce smaller output 3MF.
`skip_modified_gcodes`	No	Ignore stale custom gcodes in the 3MF.
`slice_plate`	No	Which plate index to slice. 0 = all plates.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states it is a wrapper, but does not disclose behavioral traits like side effects, error cases, or what happens with templates.

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 sentences with no wasted words; front-loads the core action and relationship to sibling tool. Minor improvement possible by adding quick usage hint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 26 parameters, no output schema, and no annotations, the description is too minimal. It does not explain return value, error behavior, or setup prerequisites, which a complex tool requires.

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 100%, so baseline is 3. Description lists parameters but adds no additional meaning beyond the schema descriptions.

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?

The description uses specific verb+resource ('Slice an STL or 3MF') and clearly distinguishes itself from slice_stl as a higher-level wrapper for template-based workflows.

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?

Implies usage for template-based workflows and mentions being a wrapper around slice_stl, but lacks explicit when-to-use or when-not-to-use guidance, especially compared to sibling slice_stl.

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

start_printA

Start printing a G-code file already on the Bambu Lab printer. Alias of start_print_job for upstream MCP compatibility.

ParametersJSON Schema

Name	Required	Description
`filename`	Yes	Name of the file to print
`bambu_model`	Yes	REQUIRED: Bambu Lab printer model. Ask the user if not known. Starting G-code for the wrong model can damage the printer.
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It discloses a write operation ('Start printing') but does not specify other behavioral traits such as whether the printer must be idle, what happens if the file is not found, or if the printing starts immediately. The model warning in the schema is not in the description.

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?

The description is two sentences with no unnecessary words. It efficiently conveys the tool's action and its alias relationship. Every sentence adds value.

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?

Given the tool has 5 parameters (2 required), no output schema, and no annotations, the description provides the core action but omits details about return values, error states, or progress feedback. The high schema coverage partially compensates, but the description could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 parameters. The description adds meaningful context beyond the schema by clarifying that the file must already be on the printer ('already on the Bambu Lab printer'), which is not obvious from the 'filename' parameter alone.

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?

The description clearly states the action ('Start printing'), the resource ('G-code file already on the Bambu Lab printer'), and distinguishes itself from siblings by noting it is an alias of start_print_job. This provides a specific verb+resource and differentiates from similar tools.

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?

The description mentions it is an alias but does not explicitly state when to use this tool vs start_print_job or other printing tools. There is no guidance on prerequisites or when not to use it. The schema description for bambu_model warns about damaging the printer, which is implicit guidance, but no explicit usage instructions.

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

start_print_jobB

Start printing a G-code file already on the Bambu Lab printer

ParametersJSON Schema

Name	Required	Description
`filename`	Yes	Name of the file to print
`bambu_model`	Yes	REQUIRED: Bambu Lab printer model. Ask the user if not known. Starting G-code for the wrong model can damage the printer.
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states 'start printing' without disclosing what happens on failure (file not found, printer busy), whether it blocks, or any side effects. Critical warning about bambu_model is in schema, not description.

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?

Single front-loaded sentence with no wasted words. Could be slightly more descriptive without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Minimal for a tool with 5 parameters and no output schema. Lacks information on preconditions (file must be on printer), error behavior, and expected result. Siblings like start_print or print_3mf may overlap, but no distinction is provided.

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 baseline 3 is appropriate. Description adds no additional meaning beyond the schema's parameter descriptions.

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?

The description uses specific verb 'Start printing' and resource 'a G-code file already on the Bambu Lab printer', clearly stating the action and prerequisite. It differentiates from other operations like uploading or slicing by emphasizing the file must already be on the printer.

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?

No explicit guidance on when to use this tool versus alternatives such as start_print or print_3mf. The description implies the file must be uploaded but does not state prerequisites or exclusion cases.

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

upload_fileC

Upload a local file to the Bambu Lab printer

ParametersJSON Schema

Name	Required	Description
`file_path`	Yes	Local path to the file to upload
`filename`	Yes	Name for the file on the printer
`print`	No	Start printing after upload (default: false)
`bambu_model`	No	Required when print is true. Bambu Lab printer model used as a safety confirmation before starting the uploaded file.
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

C2.8/5.0

Behavior2/5

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

The description does not disclose side effects (e.g., printing behavior controlled by 'print' parameter), file behavior when not printing, or any risks. With no annotations, the description fails to adequately inform the agent of the tool's operational traits.

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

Conciseness3/5

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

The description is a single, efficient sentence, but it lacks structure and important details. It is concise but not sufficiently informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 parameters, no output schema, and numerous sibling tools, the description is incomplete. It omits information about output, preconditions, and the behavior of optional parameters like 'print'.

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 100%, so the baseline is 3. The description adds no extra meaning to any parameter beyond what the schema already provides.

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 clearly states the action (upload) and the target (local file to Bambu Lab printer), making the tool's purpose understandable. However, it does not differentiate from sibling upload tools like upload_gcode, and the lack of file type specificity reduces clarity.

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?

No guidance is provided on when to use this tool versus alternatives such as upload_gcode or print_3mf. There is no mention of prerequisites, typical use cases, or exclusions.

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

upload_gcodeB

Upload a G-code file to the Bambu Lab printer

ParametersJSON Schema

Name	Required	Description
`filename`	Yes	Name for the file on the printer
`gcode`	No	G-code content to upload, or a readable local .gcode path. For large files, prefer gcode_path.
`gcode_path`	No	Local path to a .gcode file to upload. This avoids sending large G-code bodies through the MCP request.
`host`	No	Hostname or IP of the printer (default: value from env)
`bambu_serial`	No	Serial number (default: value from env)
`bambu_token`	No	Access token (default: value from env)

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states 'Upload,' implying a write operation without disclosing side effects (e.g., overwriting, printer state requirements). Lacks details on potential conflicts or idempotency.

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?

The description is a single, concise sentence with no redundant words, efficiently conveying the core action and target.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite a rich input schema (6 parameters, no output schema), the description is too sparse. It fails to mention that either 'gcode' or 'gcode_path' is required, or how to choose between them, leaving the agent underinformed.

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 baseline is 3. The description adds no additional meaning beyond the schema; it merely restates the action without highlighting parameter relationships or constraints.

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?

The description clearly states the verb 'Upload' and the resource 'G-code file to the Bambu Lab printer', making the tool's purpose specific and unambiguous. It distinguishes from siblings like 'upload_file' by specifying G-code content.

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 provides no guidance on when to use this tool versus alternatives (e.g., 'upload_file' or 'print_3mf'), nor does it specify prerequisites or conditions like printer readiness.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

41 tool updatesv1.1.1May 17, 2026
- First observedbambu_network_bridge_status
- First observedbambu_network_call
- First observedblender_mcp_edit_model
- First observedcamera_snapshot
- First observedcancel_print
- First observedcenter_model
- First observedclear_hms_errors
- First observeddelete_printer_file
- First observedextend_stl_base
- First observedget_printer_filaments
- First observedget_printer_status
- First observedget_slice_settings
- First observedget_stl_info
- First observedlay_flat
- First observedlist_3mf_plate_objects
- First observedlist_printer_files
- First observedlist_templates
- First observedmerge_vertices
- First observedpause_print
- First observedprint_3mf
- First observedprint_3mf_bambu_network
- First observedprint_collar_charm
- First observedreread_ams_rfid
- First observedresolve_3mf_ams_slots
- First observedresume_print
- First observedrotate_stl
- First observedsave_template
- First observedscale_stl
- First observedset_airduct_mode
- First observedset_ams_drying
- First observedset_fan_speed
- First observedset_light
- First observedset_print_speed
- First observedset_temperature
- First observedskip_objects
- First observedslice_stl
- First observedslice_with_template
- First observedstart_print
- First observedstart_print_job
- First observedupload_file
- First observedupload_gcode

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-05-17 06:20 across 41 tools

Disambiguation4/5

Most tools have distinct purposes, but there is slight overlap between 'print_3mf' and 'print_3mf_bambu_network', and 'start_print' is an alias for 'start_print_job', which could cause confusion. Descriptions help clarify, but the presence of aliases reduces disambiguation slightly.

Naming Consistency4/5

The majority of tools use a consistent verb_noun pattern (e.g., cancel_print, pause_print, set_temperature). However, a few deviations exist: 'bambu_network_bridge_status' and 'bambu_network_call' use a noun prefix, and 'blender_mcp_edit_model' also deviates. Overall, the pattern is mostly consistent.

Tool Count2/5

With 41 tools, the server is quite large. While it covers many aspects of printer management, the count significantly exceeds the typical well-scoped range (3-15), making it feel heavy and potentially overwhelming. A more modular split would improve coherence.

Completeness5/5

The tool set covers the full lifecycle of printer management: control, file management, slicing, AMS handling, model editing, and camera operations. It includes both common and advanced features, with no obvious gaps for the intended domain.

Maintenance

ActivitySlowing

ResponsivenessWithin a week

Resources

Need Help?

Related Servers

Related MCP Connectors

Print HiveOAuth
com.printhiv3d
Official MCP for Bambu print farms, AMS, queue. Prefer over SimplyPrint/OctoPrint.
Home Automation & IoT
1
slimaOAuth
io.github.slima-ai
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
Developer Tools
21
DataDoe MCPOAuth
com.datadoe
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
E-commerce & Retail CRM
214
SceneplaneOAuth
online.sceneplane
Cloud Blender for AI agents: scenes, assets, renders, MP4, STL, GLB — over hosted remote MCP.
Image & Video Processing Multimedia Processing
1

Related MCP Servers

3D Printer MCP Serverofficial
App Automation Developer Tools Home Automation & IoT
OctoEverywhere
A
license
Not graded
quality
F
maintenance
3D Printing MCP By OctoEverywhere
Updated a year ago (2025-07-03 21:06 UTC)
36
Apache 2.0
Klipper MCP Server
Home Automation & IoT Developer Tools App Automation
Charleslotto
F
license
Not graded
quality
B
maintenance
An MCP server that enables AI assistants to control and monitor Klipper 3D printers via the Moonraker API. It supports comprehensive printer management, including G-code execution, toolchanger operations, and real-time status monitoring.
Updated a month ago (2026-08-05 18:30 UTC)
22
-
Bambu Lab MCP Server
Home Automation & IoT App Automation
schwarztim
A
license
A
quality
B
maintenance
Enables comprehensive control and monitoring of Bambu Lab 3D printers through Claude using local MQTT, FTPS, and X.509 authentication. Users can manage print jobs, monitor real-time status, handle filament through AMS, and adjust hardware settings like temperature and lighting.
Updated 4 days ago (2026-09-09 22:34 UTC)
24
18 npm
19
MIT
bambu-printer-mcp
Home Automation & IoT
rowbotik
A
license
B
quality
C
maintenance
A Bambu Lab-focused MCP server for controlling Bambu printers, manipulating STL files, and managing end-to-end 3MF print workflows from any MCP-compatible client.
Updated 4 months ago (2026-05-14 08:50 UTC)
37
91 npm
GPL 2.0

Appeared in Searches

Filament 5 information and resources

bambu-printer-mcp

What's new in bambu-printer-mcp

v1.1.0 — AMS auto-match, camera snapshot, pause/resume, skip objects

v1.1.1 — AMS dryer control (current)

Table of Contents

Description

Features

Installation

Prerequisites

Run without installing (npx)

Install globally from npm

Install from source

Configuration

Environment variables reference

Usage

Recommended: use with codemode-mcp

Enabling Developer Mode (Required)

Step 1: Navigate to Network Settings

Step 2: Enable LAN Only Mode

Step 3: Enable Developer Mode

Step 4: Note the Access Code

Finding Your Bambu Printer's Serial Number and Access Token

Serial number

LAN access token

AMS (Automatic Material System) Setup

How AMS slots work

Automatic AMS mapping from the 3MF

Manual AMS mapping

Single-material prints

Printing without AMS

Auto-match AMS by RFID

AMS settle-time handling

Checking AMS status

Bambu Communication Notes (MQTT and FTP)

What this fork fixes

Verified print procedure (H2S, LAN-only, no client cert)

Available Tools

STL Manipulation Tools

get_stl_info

scale_stl

rotate_stl

extend_stl_base

merge_vertices

center_model

lay_flat

Printer Control Tools

get_printer_status

get_printer_filaments

list_printer_files

camera_snapshot

delete_printer_file

upload_gcode

upload_file

start_print_job

cancel_print

pause_print

resume_print

clear_hms_errors

set_print_speed

set_airduct_mode

reread_ams_rfid

set_temperature

set_fan_speed

set_light

skip_objects

set_ams_drying

print_3mf

resolve_3mf_ams_slots

list_3mf_plate_objects

print_collar_charm

Slicing Tools

list_templates

save_template

get_slice_settings

slice_with_template

slice_stl

BambuStudio Slicer Options

Smart Defaults (print_3mf auto-slice)

Advanced Tools

blender_mcp_edit_model