Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

estimate_cost

Read-only

Calculate a 3D print job's material and electricity cost from an already-sliced G-code file, using filament totals and printer power settings.

Instructions

Estimate the cost of a print job from a G-code file (already-sliced only).

        For STL/OBJ files, use ``slice_and_estimate`` instead — it slices
        and estimates in one step.

        The slicer's own ``filament used`` totals are the filament
        figures when the file carries them; otherwise Kiln counts the
        extruding moves itself.  ``estimate.filament_source`` says which,
        and a ``warnings`` entry names both numbers when Kiln's count
        sits more than 5% from the slicer's total.

        Each filament is priced as the material the file was sliced
        for; ``estimate.filaments`` lists them and
        ``estimate.material_source`` says where the material came from.
        When Kiln's servers answer, the estimate also
        carries a ``cost_intelligence`` field; what it holds depends on
        the tier.

        Args:
            file_path: Path to the G-code file.
            material: Filament material (PLA, PETG, ABS, TPU, ASA, NYLON,
                PC, …).  Leave empty to use what the file was sliced
                for, PLA when it names nothing; a named material prices
                every filament.
            electricity_rate: Cost per kWh in USD (default 0.12).
            printer_wattage: Printer power consumption in watts (default 200).
            printer_id: Optional registered printer the print is for;
                passed on with the file when kiln-pro is asked.

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_cost"
  }
}

Input Schema

NameRequiredDescriptionDefault
materialNoFilament material (PLA, PETG, ABS, TPU, ASA, NYLON, PC, …). Leave empty to use what the file was sliced for, PLA when it names nothing; a named material prices every filament. Default: "".
file_pathYesPath to the G-code file.
printer_idNoOptional registered printer the print is for; passed on with the file when kiln-pro is asked. Default: "".
printer_wattageNoPrinter power consumption in watts (default 200). Default: 200.0.
electricity_rateNoCost per kWh in USD (default 0.12). Default: 0.12.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.5.1
    • changedInput schema / properties / electricity_rate / description
      Previous value: -"Default: 0.12."New value: +"Cost per kWh in USD (default 0.12). Default: 0.12."
    • addedInput schema / properties / file_path / description
      Added value: +"Path to the G-code file."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"\"."New value: +"Filament material (PLA, PETG, ABS, TPU, ASA, NYLON, PC, …).  Leave empty to use what the file was sliced for, PLA when it names nothing; a named material prices every filament. Default: \"\"."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional registered printer the print is for; passed on with the file when kiln-pro is asked. Default: \"\"."
    • changedInput schema / properties / printer_wattage / description
      Previous value: -"Default: 200.0."New value: +"Printer power consumption in watts (default 200). Default: 200.0."
  2. Changed7 schema fields changedv1.5.0
    • removedInput schema / properties / electricity_rate / default
      Removed value: -0.12
    • addedInput schema / properties / electricity_rate / description
      Added value: +"Default: 0.12."
    • removedInput schema / properties / material / default
      Removed value: -"PLA"
    • addedInput schema / properties / material / description
      Added value: +"Default: \"\"."
    • addedInput schema / properties / printer_id
      Added value: +{
+  "description": "Default: \"\".",
+  "title": "Printer Id",
+  "type": "string"
+}
    • removedInput schema / properties / printer_wattage / default
      Removed value: -200
    • addedInput schema / properties / printer_wattage / description
      Added value: +"Default: 200.0."
  3. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare this a safe, closed read, and the description adds real substance beyond that: which filament figure wins (slicer totals vs. Kiln's own move count), the 5% divergence warning, per-filament material pricing, and the optional cost_intelligence field that only appears when servers answer. What cost_intelligence actually contains is left deliberately vague ('depends on the tier').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose and the sibling redirect, which is good. But the Args section duplicates schema descriptions almost word for word, inflating the definition without adding value, and the middle paragraph is dense with backtick-quoted field names.

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?

No output schema exists, so the description carries the return-value burden itself, and it does so by naming estimate.filament_source, estimate.filaments, estimate.material_source, warnings, and cost_intelligence. The only real gap is that cost_intelligence's contents are unspecified, which matters for tier-dependent behaviour.

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% and the Args block largely restates the schema text verbatim, including the fallback rules for material. Marginal added meaning (a named material prices every filament) is already in the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Estimate the cost of a print job from a G-code file') plus a hard scope qualifier ('already-sliced only'). Names the sibling that handles the adjacent case, so an agent can distinguish it from slice_and_estimate without opening a schema.

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?

Explicitly routes STL/OBJ inputs to slice_and_estimate, which is the main ambiguity an agent would hit. However, the crowded cost-estimation neighbourhood (estimate_material_cost, estimate_print_cost_from_mesh, print_cost_intelligence, estimate_batch_cost) is never addressed, so the agent gets no guidance on those.

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