Skip to main content
Glama
Sign In
bambu-printer-mcp

bambu-printer-mcp

by DMontgomery40
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

skip_objects

DestructiveIdempotent

Skip selected object copies during an active multi-object 3D print by sending the printer's MQTT skip command, using object IDs from the sliced 3MF file.

Instructions

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "object_ids": "<object_ids>"
    },
    "name": "skip_objects"
  }
}

Input Schema

NameRequiredDescriptionDefault
hostNoHostname or IP of the printer (default: value from env)
object_idsYesidentify_id values of the object copies to skip. Use list_3mf_plate_objects on the sliced 3MF to find them.
bambu_tokenNoAccess token (default: value from env)
bambu_serialNoSerial number (default: value from env)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.77
    • changedInput schema / properties / object_ids / description
      Previous value: -"Object IDs to skip. Use list_3mf_plate_objects on the sliced 3MF to find IDs."New value: +"identify_id values of the object copies to skip. Use list_3mf_plate_objects on the sliced 3MF to find them."
  2. First observedv1.1.1

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, openWorldHint=true and readOnlyHint=false, so the safety profile is known. The description adds that the operation goes over the printer's MQTT command channel and requires an in-progress print, but says nothing about whether a skip is reversible, whether it affects remaining copies only, or what happens if the print is paused.

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 front-loaded sentence with the action first and the precondition second; every clause carries information and there is no filler.

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 destructive, open-world mutation with no output schema, the description covers the what and the when but omits consequences: whether skipping is permanent for the job, whether it can be undone, and what feedback the caller receives. Adequate but with clear gaps given the destructive annotation.

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%, including a pointer to list_3mf_plate_objects for finding identify_id values, so the schema does the heavy lifting. The description adds no meaning beyond the schema, which is acceptable at the baseline for fully documented parameters.

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 gives a specific verb and resource (skip object IDs) and scopes it to a running multi-object print, which is clearly distinct from sibling tools like start_print, pause_print or list_3mf_plate_objects. It stops short of naming an alternative sibling explicitly, so it is clear but not maximally differentiated.

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?

"During a running multi-object print" implies the timing precondition — the print must already be active — but this is left implicit rather than stated as a rule. No alternatives (e.g. cancel_print, pause_print) or when-not-to-use conditions are given.

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

Deploy Server

Other Tools