Skip to main content
Glama

decorate_during_print_fleet

Apply the same decoration to multiple paused 3D printers at once, so a fleet can resume with consistent debossed designs.

Instructions

Apply the same decoration to N paused printers at once (Business+).

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": {
      "decoration": "<decoration>",
      "printers": "<printers>"
    },
    "name": "decorate_during_print_fleet"
  }
}

Input Schema

NameRequiredDescriptionDefault
bevelNoSlant the carved walls over the top layers for cleaner edges. Defaults to ``True``. Default: true.
bed_tempNoBed temperature, read and checked the same way as ``hotend_temp``.
depth_mmNoDeboss depth in mm, (0, 5], the same on every printer. Defaults to 1.2. Default: 1.2.
printersYesRequired, non-empty: one spec dict per paused printer, as described above. Names must be unique (an entry without one is ``"default"``); duplicates are refused.
thresholdNoHeightmap value above which a pixel is carved away (0.0-1.0). Defaults to 0.35. Default: 0.35.
decorationYesPlain-language spec string (``photo:``, ``logo:``, a texture name, or a description), applied to every printer.
hotend_tempNoNozzle temperature for every printer's resume. Unset, each printer uses its own print's, read off its G-code.
image_scaleNo0.0-1.0, what fraction of each top face the image fills. Defaults to 0.7. Default: 0.7.
aspect_policyNo``"auto_crop"`` (default), ``"auto_scale"`` or ``"strict"``: how to handle an aspect mismatch between the image and the top face. Default: "auto_crop".
filament_typeNoThe prints' material, applied to every printer. Unset, Kiln reads each print's own; a printer whose print names none is refused.
parent_design_idNoOptional design these prints derive from, recorded in each session's provenance. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv1.5.1
    • changedInput schema / properties / aspect_policy / description
      Previous value: -"Default: \"auto_crop\"."New value: +"``\"auto_crop\"`` (default), ``\"auto_scale\"`` or ``\"strict\"``: how to handle an aspect mismatch between the image and the top face. Default: \"auto_crop\"."
    • changedInput schema / properties / bed_temp / description
      Previous value: -"Default: 65."New value: +"Bed temperature, read and checked the same way as ``hotend_temp``."
    • changedInput schema / properties / bevel / description
      Previous value: -"Default: true."New value: +"Slant the carved walls over the top layers for cleaner edges. Defaults to ``True``. Default: true."
    • addedInput schema / properties / decoration / description
      Added value: +"Plain-language spec string (``photo:``, ``logo:``, a texture name, or a description), applied to every printer."
    • changedInput schema / properties / depth_mm / description
      Previous value: -"Default: 1.2."New value: +"Deboss depth in mm, (0, 5], the same on every printer. Defaults to 1.2. Default: 1.2."
    • changedInput schema / properties / filament_type / description
      Previous value: -"Default: \"PLA\"."New value: +"The prints' material, applied to every printer. Unset, Kiln reads each print's own; a printer whose print names none is refused."
    • changedInput schema / properties / hotend_temp / description
      Previous value: -"Default: 220."New value: +"Nozzle temperature for every printer's resume. Unset, each printer uses its own print's, read off its G-code."
    • changedInput schema / properties / image_scale / description
      Previous value: -"Default: 0.7."New value: +"0.0-1.0, what fraction of each top face the image fills. Defaults to 0.7. Default: 0.7."
    • changedInput schema / properties / parent_design_id / description
      Previous value: -"Default: \"\"."New value: +"Optional design these prints derive from, recorded in each session's provenance. Default: \"\"."
    • addedInput schema / properties / printers / description
      Added value: +"Required, non-empty: one spec dict per paused printer, as described above. Names must be unique (an entry without one is ``\"default\"``); duplicates are refused."
    • changedInput schema / properties / threshold / description
      Previous value: -"Default: 0.35."New value: +"Heightmap value above which a pixel is carved away (0.0-1.0). Defaults to 0.35. Default: 0.35."
  2. Addedv1.5.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already establish it is a non-read-only, non-destructive, closed-world operation, and the title confirms the fleet scope. The description adds the useful Business+ entitlement gate, but says nothing about failure semantics (partial fleet failure, atomicity), whether print state changes (pause/resume), or that the operation targets only already-paused prints — all material for a batch mutation.

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?

A single front-loaded sentence names the action, the scope, and the plan gate with zero filler. Nothing in it is redundant with the name alone, and it is sized appropriately for a tool whose parameters are fully documented in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters, a complex per-printer list structure, and no output schema, the description is thin: it gives no sense of what the call returns, how per-printer failures are reported, or the ordering/consistency guarantees across the fleet. The rich schema and annotations compensate for much of this, keeping it at minimum-viable rather than inadequate.

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%, so the schema already documents all 11 parameters including per-printer spec dicts, uniqueness rules, and defaults. The description adds no parameter-level meaning beyond that baseline, and notably never mentions that the same decoration string is broadcast to every printer entry.

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 specific verb and resource with scope: "Apply the same decoration to N paused printers at once." An agent can immediately tell this is the fleet/batch variant rather than a single-printer decoration. It stops short of naming the sibling it differs from (decorate_during_print / batch_decorate), which would have made it a 5.

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?

Usage is implied by "N paused printers at once" and the "(Business+)" tier gate, which signals a prerequisite and a plan requirement. However, there is no explicit when-not guidance, no mention of what to use for a single printer, and no statement about what happens if some target printers are not currently paused.

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