bambu-printer-mcp

Overview Schema Source Related Servers Discussions Admin

counterpart_print_assess

Idempotent

Saves a client vision observation against an exact saved job, artifact, and frame hash, keeping print evidence local and repeatable without camera, model, or printer control.

Instructions

Counterpart contract (counterpart/1): save a client vision worker observation against an exact saved job/artifact/frame hash. Local evidence only; no camera request, model call or printer controls. Clear visible empty expected footprint after attempted deposition reports suspect_no_extrusion, even without a usable baseline. Dark/occluded/unknown stays unknown; visible material does not verify success. Persists across restart; repeat observations are idempotent.

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": {
      "job_id": "<job_id>",
      "artifact_sha256": "<artifact_sha256>",
      "frame_id": "<frame_id>",
      "image_sha256": "<image_sha256>",
      "visibility": "<visibility>",
      "footprint_visible": "<footprint_visible>",
      "deposition": "<deposition>",
      "attempted": "<attempted>"
    },
    "name": "counterpart_print_assess"
  }
}

Input Schema

Name	Required	Description
`host`	No	Saved printer hostname or address; used only to select a local record.
`job_id`	Yes	Saved job UUID returned by counterpart_print_record.
`frame_id`	Yes	Saved printing frame ID that the client visually assessed.
`attempted`	Yes	The client establishes this image follows attempted object deposition. False or uncertain stays unknown; counters alone do not establish physical success.
`deposition`	Yes	Client visual observation in that footprint; absent means clearly empty, not merely an unchanged image.
`visibility`	Yes	Client visual judgement of illumination and occlusion in the expected deposition region.
`bambu_serial`	No	Saved Bambu printer serial; used only to select a local record.
`image_sha256`	Yes	Saved JPEG SHA-256 for that exact frame.
`artifact_sha256`	Yes	Exact dispatch SHA-256 returned in this job record.
`reference_empty`	No	True only if the client visually confirmed the reference footprint is empty.
`footprint_visible`	Yes	The client can locate sufficient expected deposition footprint from the sliced geometry to judge whether material is present.
`reference_frame_id`	No	Optional saved preparation-frame ID used as additional empty-bed context.
`reference_visibility`	No	Visibility of the expected footprint in the optional reference.

Output Schema

Name	Required	Description	Default
`jobs`	No
`record`	No
`status`	Yes
`contract`	Yes
`physical`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.93Nov 12, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true and openWorldHint=false, and the description reinforces them with substantive context: local evidence only, no camera request or printer controls, persistence across restart, and hash-anchored records. The one redundancy is restating idempotency, but the local-only/evidence-only framing is genuine added behavioral value.

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?

Five compact sentences, each carrying a distinct rule (scope, no-side-effect boundaries, the extrusion heuristic, the unknown-does-not-resolve rule, persistence/idempotency). Dense and front-loaded, though the contract-version prefix and the compressed heuristic sentence take a re-read.

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?

An output schema exists, so return values need no explanation, and the description still flags the key outcome (suspect_no_extrusion) the caller should expect. For a 13-parameter evidence-recording tool it covers scope, safety boundaries, and decision semantics; only explicit sibling routing is missing.

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 coverage is 100% and the parameters carry detailed per-field descriptions (including enum meanings for visibility and deposition), so the schema does the heavy lifting. The prose adds only a light gloss — 'exact saved job/artifact/frame hash' — without clarifying relationships among the 13 parameters beyond what the schema already says, so baseline 3 applies.

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?

States a concrete verb and resource: 'save a client vision worker observation against an exact saved job/artifact/frame hash'. It also carves out what the tool is not ('no camera request, model call or printer controls'), which separates it from camera_frame and the print-control siblings, though it never names a sibling tool directly.

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?

The description encodes decision rules for the observation itself (clear+visible+empty after attempt => suspect_no_extrusion; dark/occluded/unknown stays unknown; visible material does not verify success), which is real usage guidance. However, it gives no explicit when-to-use-vs-alternative routing against siblings such as counterpart_print_progress or counterpart_print_record, so the caller must infer where this fits.

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

Deploy Server