Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

estimate_print_progress

Read-only

Estimate a running 3D print's progress and end time, split into prepare, print, cool, and post-process phases, using elapsed time and layer data or live printer status.

Instructions

Estimate print progress and when the print running now will end.

        Breaks a print into phases -- preparing, printing, cooling, and
        post-processing -- from how far it has got and how long it has
        run.  When the printer has finished enough prints Kiln started,
        ``learned_time_left`` says when this one should end by its own
        record (the slicer's time for the file, as this printer really
        prints it), beside the printer's own countdown.

        Supply ``elapsed_seconds``, ``total_layers``, and ``current_layer``
        when available; any omitted values will be read from the printer's
        live status.

        :param printer_name: Printer running the job.
        :param elapsed_seconds: Seconds elapsed since print start.  Omit to
            read from printer status.
        :param total_layers: Total layer count for the job.  Omit to read
            from printer/G-code metadata.
        :param current_layer: Current layer being printed.  Omit to read
            from printer status.

        See also: ``printer_status()``, ``get_print_outcomes()``.

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": {
      "printer_name": "<printer_name>"
    },
    "name": "estimate_print_progress"
  }
}

Input Schema

NameRequiredDescriptionDefault
printer_nameYesPrinter running the job.
total_layersNoTotal layer count for the job. Omit to read from printer/G-code metadata.
current_layerNoCurrent layer being printed. Omit to read from printer status.
elapsed_secondsNoSeconds elapsed since print start. Omit to read from printer status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • addedInput schema / properties / current_layer / description
      Added value: +"Current layer being printed.  Omit to read from printer status."
    • addedInput schema / properties / elapsed_seconds / description
      Added value: +"Seconds elapsed since print start.  Omit to read from printer status."
    • addedInput schema / properties / printer_name / description
      Added value: +"Printer running the job."
    • addedInput schema / properties / total_layers / description
      Added value: +"Total layer count for the job.  Omit to read from printer/G-code metadata."
  2. Changed3 schema fields changedv1.5.0
    • removedInput schema / properties / current_layer / default
      Removed value: -null
    • removedInput schema / properties / elapsed_seconds / default
      Removed value: -null
    • removedInput schema / properties / total_layers / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already establish this is a safe, local read. The description adds real behavior: the print is decomposed into preparing/printing/cooling/post-processing phases, and learned_time_left only appears once Kiln has recorded enough prints on that printer, presented alongside the printer's own countdown. That conditional-output behavior is not derivable from annotations or schema.

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?

Purpose is front-loaded in the first line, followed by the phase/ETA explanation and then parameter notes. Sentences are dense but each carries information; the repeated param list is mildly redundant with the schema but not bloated.

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?

With no output schema, the description does the work of indicating what comes back (phase breakdown and a learned time-left estimate versus the printer's countdown), which is what an agent needs to interpret results. It stops short of enumerating the response fields, but the key output concepts are covered.

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 schema already states 'Omit to read from printer status' for each optional parameter, so the description's parameter notes largely restate the schema. No additional format, unit, or edge-case semantics are supplied beyond what the schema says.

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?

The opening sentence names a specific verb and resource ('Estimate print progress') and adds the scope of predicting when the running job ends. It introduces distinguishing concepts (phase breakdown, learned_time_left) that separate it from a plain status read, though it does not explicitly contrast with the many sibling estimate/monitor tools.

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?

It tells the agent which optional inputs to supply 'when available' and that omitted values fall back to live printer status, which is genuine usage guidance. However, the 'See also' siblings (printer_status, get_print_outcomes) are listed without saying when to prefer them over this tool, so the alternative-selection guidance is only implied.

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