Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

predict_print_failure_risk

Read-only

Warn of print failures before they happen by analyzing live telemetry, job layer data, and printer state; returns watch or high-risk status during active 3D prints.

Instructions

Warn of a failure BEFORE it happens, while the print runs.

Free door, tiered answer — Free: Clear, watch or high risk, 10 prints a day · Pro: + What is drifting and why, every print · Business: ✓ · Enterprise: ✓.

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": {
      "telemetry": "<telemetry>"
    },
    "name": "predict_print_failure_risk"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_infoNoThe job: ``job_id`` or ``file_name`` (which print this is), ``layer``, ``layer_times_s``, ``estimated_layer_time_s``.
telemetryYesThe current reading, with keys like ``hotend_temp``, ``hotend_target``, ``bed_temp``, ``flow_ratio`` (and ``vibration_rms`` / ``acoustic_band_2k_4k`` where the printer has them).
printer_idNoThe printer, as the caller names it. Also consults the recorded nozzle-lifetime state for a bounded ``nozzle_wear`` signal.
telemetry_historyNoNot read. Kept so older callers keep working; Kiln keeps the print's readings itself.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.1

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already establish readOnly, non-destructive, closed-world behavior, and the description adds important pre-failure timing plus the Free-tier cap of 10 prints per day and tier-dependent output detail. It omits auth requirements and exact response shape, so 4 rather than 5.

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?

The first sentence is front-loaded and waste-free. The tier line is compact and carries rate-limit and output-detail information, though 'Business: ✓ · Enterprise: ✓' is cryptic and slightly marketing-flavored.

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 usefully signals tiered outputs (clear/watch/high risk, drift explanation) and a daily quota. Inputs are fully covered by the schema, so an agent has enough to call it, though missing sibling routing and the unclear Business/Enterprise line keep it from 5.

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 telemetry, job_info, printer_id, and the ignored telemetry_history field are already documented in the schema. The description adds no parameter-level syntax or format beyond 'while the print runs', so the baseline 3 is appropriate.

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 first sentence gives a specific verb ('Warn') and resource ('a failure') plus timing ('BEFORE it happens, while the print runs'), making the predictive purpose clear. It does not explicitly distinguish this from close siblings such as predict_print_failure or detect_print_failure, which keeps it at 4.

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 guidance on when to choose this over predict_print_failure, detect_print_failure, or analyze_print_failure; the only conditional content is pricing and tier gating. 'While the print runs' implies live use but is not an explicit when-to-use rule.

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