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

bambu-printer-mcp

by DMontgomery40
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

inspect_print_file

Read-onlyIdempotent

Inspect a prepared sliced 3MF or G-code file and selected plate offline to return versioned file-only evidence; use it to verify details before dispatch without contacting a printer.

Instructions

Inspect an exact private snapshot of a prepared sliced 3MF or textual G-code file and selected plate without contacting a printer. Returns versioned file-only evidence; no printer readiness or permission to dispatch is established. Does not auto-slice.

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": {
      "file_path": "<file_path>",
      "bambu_model": "<bambu_model>"
    },
    "name": "inspect_print_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
bed_typeNoOptional declared bed type to compare with file metadata.
file_pathYesLocal prepared .3mf or textual .gcode artifact to inspect; checksum-only and unsliced projects reject.
bambu_modelYesExplicit file-inspection target model; never inferred from environment or live state.
plate_indexNoZero-based selected plate; defaults to 0. Raw G-code only supports 0.
include_previewNoAlso return preview: PNG pictures drawn from this exact file's G-code (every extruding line in its filament's colour; the top as it sits on the bed, and the bed side turned over), with the artifact's sha256. Large (tens of KB of base64); for apps that show the person what will print, not for agents.
nozzle_diametersNoOptional requested nozzle diameters to compare with file declarations; this does not observe installed hardware.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.61
    • addedInput schema / properties / include_preview
      Added value: +{
+  "description": "Also return preview: PNG pictures drawn from this exact file's G-code (every extruding line in its filament's colour; the top as it sits on the bed, and the bed side turned over), with the artifact's sha256. Large (tens of KB of base64); for apps that show the person what will print, not for agents.",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv1.1.42
    • changedInput schema / properties / bambu_model / enum
      Previous value: -[
-  "p1s",
-  "p1p",
-  "p2s",
-  "x1c",
-  "x1e",
-  "a1",
-  "a1mini",
-  "h2d",
-  "h2s",
-  "h2c",
-  "x2d"
-]New value: +[
+  "p1s",
+  "p1p",
+  "p2s",
+  "x1c",
+  "x1e",
+  "a1",
+  "a1mini",
+  "h2d",
+  "h2dpro",
+  "h2s",
+  "h2c",
+  "x2d"
+]
  3. Addedv1.1.27

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description still adds real behavioral context beyond them: the result is 'versioned file-only evidence', it establishes no printer readiness or dispatch permission, and it will not auto-slice. It does not describe error modes or what 'versioned evidence' contains in practical terms.

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?

Three compact sentences, front-loaded with the core action and followed by the two most important negative constraints (no printer contact, no auto-slice). Some phrasing is dense ('versioned file-only evidence') but nothing is redundant.

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 six-parameter inspection tool with no output schema, the description states the return nature (versioned, file-derived), the offline guarantee, and the no-slicing boundary. It leaves the failure conditions (checksum-only and unsliced rejection) to the schema rather than repeating them, which is acceptable given full schema coverage.

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 the parameter descriptions are unusually thorough, so the schema carries nearly all semantic weight. The prose adds only the notion of an 'exact private snapshot' and 'selected plate', which is already conveyed by file_path and plate_index; baseline 3 applies.

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: 'Inspect an exact private snapshot of a prepared sliced 3MF or textual G-code file and selected plate.' It immediately scopes the tool apart from siblings by stating 'without contacting a printer' and 'Does not auto-slice', distinguishing it from print_3mf, start_print_job, and slice_stl without opening any 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 a clear usage context — file-only inspection before dispatch, with no printer readiness or permission to dispatch established — which implicitly routes the agent away from the print/upload siblings. It does not explicitly name an alternative tool for the dispatch case, so it stops short of full when/when-not guidance.

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