Skip to main content
Glama
danielefinocchiaro

unofficial-bambu-mcp

send_to_printer

Prepares a plate's print file and sends it to a Bambu printer by opening the file in official software, saving it, or starting a confirmed LAN print.

Instructions

Make the print file of one plate (.gcode.3mf) and send it. via = auto (Bambu Connect if installed, otherwise Bambu Studio) | bambu_connect | bambu_studio: open it in an official Bambu app, where the user checks printer and AMS mapping and presses Print/Send. via = file: only make the file. via = lan: copy it to the printer on the local network and START PRINTING, for printers in LAN-only mode with Developer Mode (print farms; in cloud mode the printer refuses and the answer says so). Two steps: without confirm nothing is sent, the answer gives the AMS slots it would use and a code; check with the user that the plate is clear, then call again with confirm=. AMS slots: from use_ams_filaments, or ams_slots (one AMS slot per project filament slot, 0 = automatic), or the tray with the same type and the closest color. Tell the user the time, weight and filaments of the plate (and for lan, follow it with printer_status).

Input Schema

NameRequiredDescriptionDefault
viaNoauto
plateNo
confirmNo
ams_slotsNo
timelapseNo
bed_levelingNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and discloses important behavior: lan mode starts printing, cloud mode may refuse, file mode only creates the file, and confirmation is required before sending. It does not fully discuss permissions, material consumption, or the exact return shape, but it is substantially transparent.

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 long but appropriately dense for a multi-mode tool. The purpose is front-loaded, then the via modes, safety workflow, and AMS resolution are laid out in a structured way with little wasted text.

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 complex printing action with six parameters, no annotations, and no output schema, the description covers most of what an agent needs: mode selection, confirmation semantics, AMS slot resolution, and follow-up guidance. The missing timelapse and bed_leveling explanations keep it from being fully 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 0%, so the description must document parameters, and it does explain via, confirm, ams_slots, and implicitly plate. However, timelapse and bed_leveling are not mentioned at all, leaving two of six parameters without semantic guidance.

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 opens with a specific verb and resource: make the print file for one plate (.gcode.3mf) and send it. It also distinguishes the supported delivery modes, so an agent can tell this apart from slicing-only or preview-only siblings.

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

Usage Guidelines5/5

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

It explicitly defines when to use each via mode: auto, bambu_connect, bambu_studio, file, and lan. It also states the LAN prerequisites and the two-step confirmation workflow, which is exactly the guidance needed to choose the right path.

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