bambu-printer-mcp

Overview Schema Source Related Servers Discussions Admin

counterpart_propose_filaments

Read-onlyIdempotent

Proposes the nearest loaded AMS spool for each model filament by color and material, then validates chosen spools against the current AMS load before slicing.

Instructions

Counterpart contract (counterpart/1): which loaded AMS spool prints each of a model's colours, before slicing. Reads the live AMS once. trays lists the spools a person may choose (label like "A2", a person-readable name, colour, material, feed). proposal gives each filament its nearest spool in OKLab colour with the asked-for material preferred, and a verdict: same-colour, closest (that colour isn't loaded; note says so), no-colour or none. One print feeds from one source. Pass chosen to check the person's spools against what is loaded now; mapping then lists every filament slot's spool (painted slots included), and problems says why a choice can't print.

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": {
      "filaments": "<filaments>"
    },
    "name": "counterpart_propose_filaments"
  }
}

Input Schema

Name	Required	Description
`host`	No	Hostname or IP of the printer (default: value from env)
`chosen`	No	The person's spool for each filament, in the same order: checked against what is loaded now. Omit for the proposal alone.
`sliced`	No	The file is already sliced: its materials are fixed, so only spools of the same material qualify.
`painted`	No	Filament slots no part names (painted regions). Each follows the chosen spools' feed; prints false when the selected plate never uses it.
`filaments`	Yes	The model's filaments a person sees, in project order: 1-based index, part name, the colour it belongs in and its material when known.
`bambu_model`	No	Printer model; defaults to BAMBU_MODEL. Selects the filament profiles that decide which spools can slice.
`bambu_token`	No	Access token (default: value from env); never returned.
`bambu_serial`	No	Serial number (default: value from env)
`nozzle_diameter`	No	Nozzle diameter (default NOZZLE_DIAMETER or 0.4).

Output Schema

Name	Required	Description	Default
`trays`	Yes
`mapping`	No
`contract`	Yes
`problems`	Yes
`proposal`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.77Nov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the read-only, open-world annotations, the description discloses that it reads the live AMS once, computes nearest spools in OKLab colour with material preference, returns verdict types, and enforces one print feeding from one source. It also explains what chosen adds, including mapping and problems. This is rich behavioral context for a read-only tool.

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?

The description is front-loaded with the core contract and purpose, then proceeds through trays, proposal verdicts, and chosen validation. It is dense and jargon-heavy but every sentence provides relevant information for a complex tool. Minor tightening could improve readability, but it is appropriately sized.

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?

Given the tool's complexity, nine parameters, rich schema, output schema, and annotations, the description is complete enough. It covers the live AMS read, trays, proposal verdicts, the one-print-one-source constraint, and the chosen validation path including mapping and problems. Nothing critical for correct invocation appears 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 documents each parameter thoroughly. The description still adds useful meaning for chosen by explaining that it checks the person's spools against what is loaded now and triggers mapping and problem reporting. It does not go deeply into every parameter, but it complements the schema well.

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 states a specific purpose: mapping each of a model's colours to a loaded AMS spool before slicing. It distinguishes the operation from nearby tools by emphasizing the live AMS read, proposal verdicts, and optional validation of a person's chosen spools. An agent can identify this as the pre-slicing filament/spool matching tool.

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 clearly establishes the main usage context: before slicing, to propose spools or check a person's choices via chosen. It does not explicitly name alternatives such as resolve_3mf_ams_slots or state when not to use it, but the context is clear enough to guide selection.

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

Deploy Server