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

bambu-printer-mcp

by DMontgomery40
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

resume_print

Idempotent

Resume a paused print job started by this server after re-downloading its file over FTPS, verifying SHA-256, and rechecking printer state; ask for confirmation only if the file cannot be re-read.

Instructions

Resume a paused job that this server inspected and started. It re-downloads the job's file over FTPS and compares its SHA-256, asks a person to confirm only when the file could not be re-read, and reads the printer again before sending. A job that was cancelled, ended or replaced is never resumed. Returns jobName and bytesVerified.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "resume_print"
  }
}

Input Schema

NameRequiredDescriptionDefault
hostNoHostname or IP of the printer (default: value from env)
bambu_tokenNoAccess token (default: value from env)
bambu_serialNoSerial number (default: value from env)
connection_modeNoThe connection the print used. Defaults to BAMBU_DEFAULT_CONNECTION_MODE, the same default print_3mf uses, else the model's route.
connection_typeNoFULU BambuNetwork connection type the print used. Defaults to BAMBU_DEFAULT_CONNECTION_TYPE, as for print_3mf. Authenticated controls support lan.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.61
    • addedInput schema / properties / connection_mode
      Added value: +{
+  "description": "The connection the print used. Defaults to BAMBU_DEFAULT_CONNECTION_MODE, the same default print_3mf uses, else the model's route.",
+  "enum": [
+    "lan_mqtt_ftps",
+    "bambu_network",
+    "bambu_native"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / connection_type
      Added value: +{
+  "description": "FULU BambuNetwork connection type the print used. Defaults to BAMBU_DEFAULT_CONNECTION_TYPE, as for print_3mf. Authenticated controls support lan.",
+  "enum": [
+    "lan",
+    "cloud"
+  ],
+  "type": "string"
+}
  2. First observedv1.1.1

TDQS

A4.5/5.0
Behavior5/5

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

Far beyond the annotations: it discloses the re-download over FTPS with SHA-256 comparison, that a human confirmation is solicited only when the file cannot be re-read, that printer state is re-read before sending, and that cancelled/ended/replaced jobs are refused. The annotations only declare the safety profile (non-read-only, idempotent, non-destructive); the actual resume semantics come entirely from 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?

Four dense sentences, front-loaded with the identity of the operation, followed by verification behavior, the human-confirmation exception, and the refusal case. No filler and no repetition of the tool name.

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?

For a mutation tool with no output schema, the description covers the sequence of operations, the confirmation gate, the failure exclusions, and even the return fields (jobName, bytesVerified). An agent can predict outcomes and preconditions without reading code.

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% and every parameter already has a description and defaults, so the description adds no parameter meaning. Baseline 3 is appropriate; it does not explain how connection_mode must match the original print, though the schema hints at 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?

States a specific verb and resource ('Resume a paused job') plus a key qualifier ('that this server inspected and started'), which cleanly separates it from start_print_job, pause_print, and cancel_print without needing either schema.

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 gives explicit when-not conditions ('A job that was cancelled, ended or replaced is never resumed'), which is useful routing guidance, but it never names an alternative tool to use when resume is refused, leaving the fallback path implicit.

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