Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

assess_fleet_power_loss

Read-only

Triage an entire 3D printer fleet after a power loss, scoping affected printers and failures to guide recovery across mixed brands and models.

Instructions

Triage a whole fleet after a power loss — mixed brands/models (Business+).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "assess_fleet_power_loss"
  }
}

Input Schema

NameRequiredDescriptionDefault
failuresNo``{printer_name: failure_id}`` for the affected printers (from ``detect_print_failure`` per printer). Scopes the triage and enables per-Klipper probe suggestions. Omit to assess every registered printer (no suggestions).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / failures / description
      Added value: +"``{printer_name: failure_id}`` for the affected printers (from ``detect_print_failure`` per printer).  Scopes the triage and enables per-Klipper probe suggestions.  Omit to assess every registered printer (no suggestions)."
  2. Addedv1.5.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already establish that this is a read-only, non-destructive, closed-world operation, so the bar for behavioral disclosure is lower. The description adds useful scope and entitlement context ('whole fleet,' 'mixed brands/models,' 'Business+'), but it does not explain what the triage output contains or how results should be interpreted.

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?

The description is a single front-loaded sentence with no filler. It communicates the operation, scope, fleet heterogeneity, and tier requirement efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only fleet triage operation, the description gives enough context to select the tool. However, with no output schema, it leaves the nature of the triage result unspecified, and it does not clarify how this differs from other power-loss recovery or fleet-status tools.

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 failures parameter is already richly documented in the schema, including the distinction between scoped triage and omitting it to assess every registered printer. The description adds no parameter-specific detail beyond implying whole-fleet scope, 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 description uses a specific verb, 'Triage,' and a clearly scoped resource, 'a whole fleet after a power loss.' It also clarifies that mixed brands/models are supported, which helps distinguish it from single-printer recovery tools, but it does not explicitly name or differentiate itself from related siblings like recover_power_loss_print or check_power_loss_recovery.

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?

The description gives clear usage context: use it after a power loss on an entire fleet, especially with mixed brands/models, and notes a Business+ requirement. It does not provide explicit when-not-to-use guidance or name alternative tools for narrower recovery scenarios.

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