Skip to main content
Glama

batch_estimate_plate_part_costs

Read-only

Estimate per-part material and electricity costs for multiple sliced plates in one batch, with shared defaults and per-item overrides for material, filament price, and power.

Instructions

Batch-estimate per-part economics for many sliced plates (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": {
      "items": "<items>"
    },
    "name": "batch_estimate_plate_part_costs"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemsYesThe plates to estimate, a non-empty list of dicts in the shape above; the list length is capped. An item that is not a dict, or has no ``file_path``, is reported as an error and skipped.
materialNoThe default material for every item that does not name its own; defaults to ``PLA``. Default: "PLA".
cost_per_kg_usdNoThe default filament price in US dollars per kilogram for every item that does not name its own. Omitted, Kiln's built-in price for the material is used; must not be negative.
printer_wattageNoThe default average power draw in watts for every item, 200 unless set; must not be negative. Default: 200.0.
electricity_rateNoThe default electricity price in US dollars per kWh for every item, 0.12 unless set; must not be negative. Default: 0.12.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.5.1
    • addedInput schema / properties / cost_per_kg_usd / description
      Added value: +"The default filament price in US dollars per kilogram for every item that does not name its own. 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: +"The default electricity price in US dollars per kWh for every item, 0.12 unless set; must not be negative. Default: 0.12."
    • addedInput schema / properties / items / description
      Added value: +"The plates to estimate, a non-empty list of dicts in the shape above; the list length is capped.  An item that is not a dict, or has no ``file_path``, is reported as an error and skipped."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PLA\"."New value: +"The default material for every item that does not name its own; defaults to ``PLA``. Default: \"PLA\"."
    • changedInput schema / properties / printer_wattage / description
      Previous value: -"Default: 200.0."New value: +"The default average power draw in watts for every item, 200 unless set; must not be negative. Default: 200.0."
  2. Addedv1.5.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds essentially nothing beyond that except the '(Business)' subscription tag; it does not say what the estimate covers (material, electricity, labor), how partial failures in the item list are reported, or whether results are cached.

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 or repetition. It is efficient, though its brevity is more a symptom of under-specification than of disciplined trimming.

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?

A five-parameter batch tool with no output schema and no description of the return shape leaves the agent guessing what 'per-part economics' contains and how errors in the items list surface. Given the complexity of batch estimation, the one-line description is not complete enough.

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%, with per-item overrides, defaults, and non-negative constraints already documented in the schema. The description adds no additional parameter meaning, so the baseline of 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 specific verb and resource: batch-estimating per-part economics across many sliced plates. It is distinguishable from single-plate siblings (estimate_plate_part_costs) by the 'batch/many plates' framing, though it never names those alternatives.

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?

No guidance on when to use this versus estimate_batch_cost, estimate_plate_part_costs, estimate_cost, or slice_and_estimate. The only contextual signal is the '(Business)' tier tag, which hints at availability but not selection criteria or prerequisites.

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