Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

emergency_status

Read-only

Checks whether an emergency stop is latched on one 3D printer or the entire fleet and reports if printing is locked until acknowledged clearing.

Instructions

Get the emergency stop latch status for one printer or the entire fleet.

Returns whether an emergency stop is active and whether the printer is
locked from printing operations.  When an e-stop is active, all print
commands are blocked until ``clear_emergency_stop()`` is called with an
acknowledgement note.

:param printer_name: Query a specific printer, or omit for all printers.
:param include_unlatched: When True, include printers that have no active
    latch.  Defaults to False (only active latches).

:returns: Latch state per printer: ``active`` (bool), ``reason``,
    ``source``, ``timestamp``, and whether critical interlocks prevent
    clearing.

See also: ``emergency_stop()``, ``clear_emergency_stop()``.

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": "emergency_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
printer_nameNoQuery a specific printer, or omit for all printers.
include_unlatchedNoWhen True, include printers that have no active latch. Defaults to False (only active latches). Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • changedInput schema / properties / include_unlatched / description
      Previous value: -"Default: false."New value: +"When True, include printers that have no active latch.  Defaults to False (only active latches). Default: false."
    • addedInput schema / properties / printer_name / description
      Added value: +"Query a specific printer, or omit for all printers."
  2. Changed3 schema fields changedv1.5.0
    • removedInput schema / properties / include_unlatched / default
      Removed value: -false
    • addedInput schema / properties / include_unlatched / description
      Added value: +"Default: false."
    • removedInput schema / properties / printer_name / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the readOnlyHint and destructiveHint annotations, the description explains that an active e-stop blocks all print commands until clear_emergency_stop() is called with an acknowledgement note. It also lists the returned latch fields and notes that critical interlocks can prevent clearing, adding useful behavioral context.

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 states the core purpose immediately. The Sphinx-style :param: and :returns: sections are somewhat redundant with the schema and return explanation, but the overall structure remains clear and useful.

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

Completeness5/5

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

There is no output schema, so the description carries the burden of explaining return values, and it does so by listing active, reason, source, timestamp, and interlock information. It also covers both parameters, the blocking behavior, and the related clearing action, making the definition complete for this status tool.

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 description repeats the same parameter meanings already documented in the schema. It does not add syntax, edge-case, or filtering details beyond what the schema provides, so the baseline of 3 is appropriate.

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?

The description uses a specific verb and resource: 'Get the emergency stop latch status' for one printer or the entire fleet. It clearly distinguishes this read-only status check from the sibling actions emergency_stop() and clear_emergency_stop().

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 context for when this tool is relevant and names the related action tools in 'See also'. It does not explicitly state when not to use it or fully contrast the alternatives, but the status-versus-action distinction is clear.

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