Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

plan_fleet_material_change

Destructive

Plan material and color changes for objects across a fleet of 3D printers, preparing per-device sessions and optionally executing ready jobs.

Instructions

Plan future-object material/color changes across a fleet (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": {
      "printers": "<printers>",
      "targets": "<targets>"
    },
    "name": "plan_fleet_material_change"
  }
}

Input Schema

NameRequiredDescriptionDefault
targetsYesRequired, non-empty: one dict per object to change, naming the object and its new material/colour as described above.
printersYesOne spec dict per printer, as described above. Empty plans every registered printer Kiln can discover.
output_dirNoWhere prepared sessions are written. Empty uses a new temporary work folder. Default: "".
plate_numberNoWhich plate of a multi-plate source file holds the objects. Defaults to 1; a printer spec's own ``plate_number`` wins. Default: 1.
execute_readyNoWhen ``True``, upload and start the prepared session on each ready device. This acts on the printers. Defaults to ``False``; refused through Kiln's servers. Default: false.
trigger_objectNoOptional label for the object the change is keyed to; it is recorded on each device's result and does not change the plan. Default: "".
build_artifactsNoWhen ``True``, prepare local recovery sessions for the devices that are ready. Defaults to ``False``. Refused through Kiln's servers, which only plan. Default: false.
prepared_sessionsNoSessions prepared by an earlier call, keyed by printer name, for ``execute_ready``. Sessions built in this same call are used as well. Refused through Kiln's servers.
require_ams_matchNoWhen ``True`` (the default), a route is ready only when the printer's material status proves the requested slot, type and colour. Default: true.
source_filament_typeNoThe material loaded now (the "from" side of the change). Unset, Kiln reads each print's own, then the feeding tray; a printer where none is known needs operator action. A printer spec's own value wins.
source_filament_colorNoThe colour loaded now, used the same way when judging the transition. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.1

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the key safety signal is supplied structurally; the description adds only the fleet scope and a vague '(Business)' tier hint. Framing the tool purely as 'Plan' undersells that it prepares sessions on disk and can, via execute_ready, upload and start sessions on printers. Beyond that it discloses nothing about side effects, refusals through Kiln servers, or what a successful plan leaves behind.

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?

A single front-loaded sentence with no filler, which is structurally clean. It is efficient to the point of under-specification, and the trailing '(Business)' qualifier is cryptic without explanation of what tier or licensing means for the caller.

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

Completeness2/5

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

For a destructive, 11-parameter tool with nested objects and no output schema, one sentence is far too thin; the agent must reconstruct the plan-versus-execute workflow, the fact that servers refuse build_artifacts and execute_ready, and the readiness rules entirely from the schema. Nothing is said about what a caller receives from a planning run.

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 all 11 parameters, including the nested printers and targets item semantics, are documented in the schema itself, which sets the baseline at 3. The description adds no meaning beyond that (nothing about plate_number precedence, output_dir layout, or prepared_sessions reuse), so it neither compensates nor detracts.

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?

State a specific verb and resource: 'Plan ... material/color changes across a fleet'. The scope (fleet-wide, future objects, material and colour) is clear enough that an agent can separate it from siblings like fleet_colour_match or get_fleet_material_summary without opening the schema. It stops short of a 5 because it never explicitly names a sibling or the boundary between planning and executing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not guidance in the description; the two-phase planning/execution workflow and the role of execute_ready versus build_artifacts appear only inside the parameter schema. An agent gets no cue about prerequisites (AMS match, source filament known) or about when a simpler sibling such as fleet_colour_match would suffice.

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