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

bambu-printer-mcp

by DMontgomery40
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

camera_frame

Read-onlyIdempotent

Reads the Bambu printer's shared camera stream and returns a JPEG only when a newer, visibly changed frame exists; optionally waits up to 10 seconds for one.

Instructions

Read the shared camera stream, optionally waiting up to 10 seconds. Returns JPEG only when newer than since_seq and visibly changed (32×18 grayscale difference). Retain the last delivered frame's seq on unchanged. max_width resizes JPEG to the viewer. Does not start a stopped stream.

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": "camera_frame"
  }
}

Input Schema

NameRequiredDescriptionDefault
hostNoPrinter LAN host or IP; defaults to the configured Bambu host.
wait_msNoMaximum time to await a newer changed frame; zero returns immediately.
max_bytesNoOptional maximum encoded JPEG bytes. Downscales further at quality 70 when needed; base64 adds about one third plus protocol overhead. Use 42000 for a two-second 30 KB/s viewer budget.
max_widthNoOptional maximum JPEG width in pixels, preserving aspect ratio and never enlarging.
since_seqNoSequence of the last delivered JPEG; retain it when a result is unchanged.
min_changeNoMinimum mean absolute grayscale thumbnail difference, normalized from zero to one.
bambu_tokenNoPrinter LAN access code; defaults to the configured access code.
bambu_serialNoPrinter serial number; defaults to the configured serial and identifies its shared stream.
changed_onlyNoReturn JPEG only when its thumbnail differs enough from the last delivered frame.

Output Schema

NameRequiredDescriptionDefault
seqYes
widthNo
base64No
changeNo
formatNo
heightNo
reasonNo
statusYes
capturedAtNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.61

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare a safe, idempotent, read-only, non-destructive call, and the description goes well beyond them: it discloses that a JPEG is returned conditionally (only when newer than since_seq and visibly changed), names the 32x18 grayscale comparison as the change test, explains that the caller must retain the prior seq on an unchanged result, and states the resizing side effect. The 'does not start a stopped stream' constraint is exactly the kind of precondition annotations cannot express.

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?

Five dense sentences, each carrying a distinct fact, with the primary action front-loaded and the preconditions last. No filler or restatement of the name.

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 9-parameter read tool with full schema descriptions, complete annotations and an output schema, the description covers the non-obvious contract (conditional return, seq retention, resize side effect). It does not say what happens when the stream is stopped (error vs. empty result), which is the one behavior an agent could still get wrong.

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 baseline is 3; the description nonetheless adds cross-parameter meaning by tying since_seq, min_change and wait_ms together into a single change-detection protocol, and by noting max_width resizes the JPEG for the viewer. Auth parameters (bambu_token, bambu_serial) are left entirely to the schema.

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?

The first clause gives a specific verb and resource: 'Read the shared camera stream'. The closing sentence, 'Does not start a stopped stream,' implicitly separates it from camera_stream_start, though it never names that or any other sibling (e.g. camera_snapshot) directly.

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 states the operating envelope (optional wait up to 10 seconds, zero returns immediately per the schema) and one explicit when-not condition: the stream must already be running. It stops short of naming the alternative tool to call when the stream is stopped.

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