Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

estimate_plate_part_costs

Read-only

Estimate per-part print time, filament use, and cost from a sliced .gcode.3mf plate file, including material and electricity pricing.

Instructions

Estimate per-part print time, filament, and cost for a sliced plate (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": {
      "file_path": "<file_path>"
    },
    "name": "estimate_plate_part_costs"
  }
}

Input Schema

NameRequiredDescriptionDefault
materialNoThe material name used to price every object not named in ``material_by_object``; defaults to ``PLA``. Default: "PLA".
file_pathYesPath to the sliced ``.gcode.3mf`` plate file. A missing file answers ``FILE_NOT_FOUND``; a file that is not a ZIP/3MF answers ``INVALID_INPUT``.
plate_numberNoWhich plate in the file to read, counted from 1; defaults to the first. Default: 1.
cost_per_kg_usdNoFilament price in US dollars per kilogram. Omitted, Kiln's built-in price for the material is used; must not be negative.
printer_wattageNoThe printer's average power draw in watts, defaults to 200; must not be negative. Default: 200.0.
electricity_rateNoElectricity price in US dollars per kWh, defaults to 0.12; must not be negative. Default: 0.12.
material_by_objectNoOptional map from an object name, object stem or label ID string to the material that object prints in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.5.1
    • addedInput schema / properties / cost_per_kg_usd / description
      Added value: +"Filament price in US dollars per kilogram. Omitted, Kiln's built-in price for the material is used; must not be negative."
    • changedInput schema / properties / electricity_rate / description
      Previous value: -"Default: 0.12."New value: +"Electricity price in US dollars per kWh, defaults to 0.12; must not be negative. Default: 0.12."
    • addedInput schema / properties / file_path / description
      Added value: +"Path to the sliced ``.gcode.3mf`` plate file.  A missing file answers ``FILE_NOT_FOUND``; a file that is not a ZIP/3MF answers ``INVALID_INPUT``."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PLA\"."New value: +"The material name used to price every object not named in ``material_by_object``; defaults to ``PLA``. Default: \"PLA\"."
    • addedInput schema / properties / material_by_object / description
      Added value: +"Optional map from an object name, object stem or label ID string to the material that object prints in."
    • changedInput schema / properties / plate_number / description
      Previous value: -"Default: 1."New value: +"Which plate in the file to read, counted from 1; defaults to the first. Default: 1."
    • changedInput schema / properties / printer_wattage / description
      Previous value: -"Default: 200.0."New value: +"The printer's average power draw in watts, defaults to 200; must not be negative. Default: 200.0."
  2. Addedv1.5.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the meaningful precondition that the input must be a sliced plate and that results are per-part, but it says nothing about prerequisite slicing steps, pricing source behavior, or what happens when material overrides conflict.

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, stating verb, outputs, input type, and tier in one pass. It is efficient but arguably too thin for a 7-parameter tool with a nested object map, leaving room for a short clause about output shape.

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?

Given annotations cover safety and the schema fully documents all 7 parameters, the definition is nearly sufficient to call the tool. The gap is the absence of any note about the returned per-part breakdown (no output schema exists) and the prerequisite that the plate must already be sliced, which the agent must infer from the file_path description.

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?

No parameters are undocumented in the description, and the schema already carries full descriptions for all 7 parameters, though the description itself contributes no extra meaning beyond the structured fields. The baseline for full coverage is 3, but the description's phrase 'per-part print time, filament, and cost' reinforces how material, cost_per_kg_usd, printer_wattage, and electricity_rate combine, adding slight value.

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: estimate per-part print time, filament, and cost from a sliced plate. The 'per-part' and 'sliced plate' qualifiers make it distinguishable from mesh-level estimators, but it never names its closest sibling batch_estimate_plate_part_costs, so the agent must infer the single-vs-batch distinction.

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?

The parenthetical '(Business)' implies a tier prerequisite, but the description gives no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as batch_estimate_plate_part_costs, estimate_print_cost_from_mesh, or slice_and_estimate. The agent must guess which estimator applies to its situation.

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