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

bambu-printer-mcp

by DMontgomery40
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

counterpart_make_3mf

Idempotent

Combine separately exported STL parts into one 3MF assembly for multi-colour printing, preserving relative positions and assigning each part its filament number.

Instructions

Counterpart contract (counterpart/1): combine STL parts exported separately (for example each body of a design) into one new 3MF for multi-colour printing. The parts keep their relative positions as one assembly, and each part prints with its filament number (default: part 1 uses filament 1, part 2 filament 2, and so on). Slice it with slice_stl, passing one load_filaments profile per filament number, then print it with print_3mf and ams_mapping or ams_slots. Never overwrites a file.

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": {
      "parts": "<parts>",
      "out_path": "<out_path>"
    },
    "name": "counterpart_make_3mf"
  }
}

Input Schema

NameRequiredDescriptionDefault
partsYesThe parts, in filament order.
out_pathYesNew .3mf path whose parent directory exists. Existing files are never overwritten.

Output Schema

NameRequiredDescriptionDefault
pathYesAbsolute path of the written 3MF.
partsYes
objectsYesObjects in the 3MF: one assembly.
contractYes
filamentsYesHighest filament number any part uses; pass that many load_filaments to slice_stl.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.51

TDQS

A4.7/5.0
Behavior5/5

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

Goes well past the annotations by disclosing the filament-mapping rule (part 1 -> filament 1 by default), that relative positions are preserved as one assembly, and the file-safety contract 'Never overwrites a file' — consistent with destructiveHint=false and idempotentHint=true. The prefixed contract version ('counterpart/1') also signals a stable behavioural interface.

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?

Three tight sentences: identity/action first, then assembly and filament semantics, then the slice-and-print continuation and the safety note. Every clause carries information an agent needs; nothing is padding.

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 two-parameter tool with full schema coverage, an output schema, and complete annotations, the description covers the remaining gaps: what the output is, how filaments are assigned, where it sits in the slice/print workflow, and file-overwrite safety. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100%, so the schema already carries the per-parameter documentation; the description still adds meaning by explaining the default filament derivation across the whole parts list and by reinforcing the non-overwrite guarantee on out_path. It does not add format or validation detail beyond the schema, so it stays at 4 rather than 5.

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 — combine separately exported STL parts into one new 3MF — plus the purpose (multi-colour printing) and the assembly semantics ('parts keep their relative positions as one assembly'). This is clearly distinguishable from siblings like slice_stl or extend_stl_base, which operate on single files.

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?

Gives a concrete downstream chain: slice the result with slice_stl passing one load_filaments profile per filament number, then print with print_3mf using ams_mapping or ams_slots. That is strong 'what to do next' guidance, but it never states when to avoid this tool or pick a different combine/route sibling (e.g. counterpart_print_route), so a 4 rather than a 5.

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