Kiln

Overview Schema Source Related Servers Discussions Admin

emergency_trip_input

Destructive

Triggers a software emergency stop on a specified 3D printer when an external hardware input such as a button or PLC calls in, with optional token authorization and trigger note.

Instructions

Trip emergency stop from an external hardware bridge.

Designed for physical input devices (ESP32, PLC, wired push buttons)
that call this endpoint over HTTP to trigger a software e-stop.  This
is different from ``emergency_stop()`` which is for agent/software-
initiated stops.

If ``KILN_ESTOP_INPUT_TOKEN`` is configured, the request must include
a matching ``token`` or it will be rejected.

:param printer_name: Printer to emergency-stop.
:param input_name: Label for the input source (default
    ``"external_button"``).
:param token: Authorization token -- required when
    ``KILN_ESTOP_INPUT_TOKEN`` is set.
:param note: Optional free-text note describing the trigger reason.

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

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

Input Schema

Name	Required	Description
`note`	No	Optional free-text note describing the trigger reason.
`token`	No	Authorization token -- required when ``KILN_ESTOP_INPUT_TOKEN`` is set.
`input_name`	No	Label for the input source (default ``"external_button"``). Default: "external_button".
`printer_name`	Yes	Printer to emergency-stop.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.5.1Nov 5, 2026

changedInput schema / properties / input_name / description

Previous value: -"Default: \"external_button\"."New value: +"Label for the input source (default ``\"external_button\"``). Default: \"external_button\"."

addedInput schema / properties / note / description

Added value: +"Optional free-text note describing the trigger reason."

addedInput schema / properties / printer_name / description
```
Added value: +"Printer to emergency-stop."
```

addedInput schema / properties / token / description

Added value: +"Authorization token -- required when ``KILN_ESTOP_INPUT_TOKEN`` is set."

Changed4 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / input_name / default
```
Removed value: -"external_button"
```
- addedInput schema / properties / input_name / description
```
Added value: +"Default: \"external_button\"."
```
- removedInput schema / properties / note / default
```
Removed value: -null
```
- removedInput schema / properties / token / default
```
Removed value: -null
```
First observedv0.1.0Jul 4, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real context beyond that: the optional KILN_ESTOP_INPUT_TOKEN gate and that unauthorized requests are rejected, which materially changes how a caller must prepare. It stops short of saying what state the printer is left in or that a paired clear/recovery step is needed.

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?

The opening two sentences are well front-loaded and carry the decisive differentiation. However, the Sphinx-style :param: block duplicates the fully-covered schema descriptions sentence for sentence, so a meaningful fraction of the text does not earn its place.

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?

For a four-parameter, safety-critical tool with no output schema, the description covers intent, channel, auth, and cross-references to emergency_status(). It omits post-trip behavior and whether clearing is required, which would be the remaining gap for a destructive e-stop.

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 :param: entries restate the schema descriptions almost verbatim, so no meaning is added. The only slightly useful addition is confirming the token's relationship to the environment variable, which the schema already states.

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 ('Trip emergency stop') plus the channel it applies to ('external hardware bridge'), and explicitly separates itself from the sibling emergency_stop() by describing that tool as agent/software-initiated. An agent can pick between the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the intended callers (ESP32, PLC, wired push buttons over HTTP) and names the alternative (emergency_stop()) with the condition that selects it. The when-to-use boundary is explicit rather than inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server