Kiln

Overview Schema Source Related Servers Discussions Admin

start_monitored_print

Destructive

Starts a print and automatically monitors the first layer by capturing snapshots, optionally auto-pausing on detected failure. Use for safe autonomous printing.

Instructions

Start a print and automatically monitor the first layer.

        This is the recommended way to start prints autonomously. It combines
        start_print with first-layer monitoring in a single operation:

        1. Starts the print
        2. Waits for the configured delay (default 2 minutes)
        3. Captures snapshots during first layers
        4. Returns snapshots for you to visually inspect
        5. Optionally auto-pauses if you report a failure

        Use this instead of start_print when operating autonomously (Level 1/2)
        to satisfy the first-layer monitoring safety requirement.

        Args:
            file_name: Name of the file to print (must exist on printer).
            printer_name: Target printer. Omit for default.
            first_layer_delay: Seconds to wait before first snapshot (default 120).
            first_layer_checks: Number of first-layer snapshots to capture (default 3).
            first_layer_interval: Seconds between snapshots (default 60).
            auto_pause: Auto-pause if snapshot analysis detects failure (default True).
            preview_token: Token from ``issue_preview_token`` proving this
                file was shown to the person before printing.  Required
                beside their go-ahead: a print is shown to its owner
                before it starts.

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": {
      "file_name": "<file_name>"
    },
    "name": "start_monitored_print"
  }
}

Input Schema

Name	Required	Description
`file_name`	Yes	Name of the file to print (must exist on printer).
`auto_pause`	No	Auto-pause if snapshot analysis detects failure (default True). Default: true.
`printer_name`	No	Target printer. Omit for default.
`preview_token`	No	Token from ``issue_preview_token`` proving this file was shown to the person before printing. Required beside their go-ahead: a print is shown to its owner before it starts.
`first_layer_delay`	No	Seconds to wait before first snapshot (default 120). Default: 120.
`first_layer_checks`	No	Number of first-layer snapshots to capture (default 3). Default: 3.
`first_layer_interval`	No	Seconds between snapshots (default 60). Default: 60.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.5.1Nov 5, 2026

changedInput schema / properties / auto_pause / description

Previous value: -"Default: true."New value: +"Auto-pause if snapshot analysis detects failure (default True). Default: true."

addedInput schema / properties / file_name / description

Added value: +"Name of the file to print (must exist on printer)."

changedInput schema / properties / first_layer_checks / description

Previous value: -"Default: 3."New value: +"Number of first-layer snapshots to capture (default 3). Default: 3."

changedInput schema / properties / first_layer_delay / description

Previous value: -"Default: 120."New value: +"Seconds to wait before first snapshot (default 120). Default: 120."

changedInput schema / properties / first_layer_interval / description

Previous value: -"Default: 60."New value: +"Seconds between snapshots (default 60). Default: 60."

addedInput schema / properties / preview_token / description

Added value: +"Token from ``issue_preview_token`` proving this file was shown to the person before printing.  Required beside their go-ahead: a print is shown to its owner before it starts."

addedInput schema / properties / printer_name / description
```
Added value: +"Target printer. Omit for default."
```

Changed10 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / auto_pause / default
```
Removed value: -true
```
- addedInput schema / properties / auto_pause / description
```
Added value: +"Default: true."
```
- removedInput schema / properties / first_layer_checks / default
```
Removed value: -3
```
- addedInput schema / properties / first_layer_checks / description
```
Added value: +"Default: 3."
```
- removedInput schema / properties / first_layer_delay / default
```
Removed value: -120
```
- addedInput schema / properties / first_layer_delay / description
```
Added value: +"Default: 120."
```
- removedInput schema / properties / first_layer_interval / default
```
Removed value: -60
```
- addedInput schema / properties / first_layer_interval / description
```
Added value: +"Default: 60."
```
- removedInput schema / properties / preview_token / default
```
Removed value: -null
```
- removedInput schema / properties / printer_name / default
```
Removed value: -null
```

Changed1 schema field changedv1.3.1Aug 19, 2026

addedInput schema / properties / preview_token

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Preview Token"
+}

First observedv0.1.0Jul 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: this is a long-blocking call (default 120s delay plus 3 snapshots at 60s intervals), it returns snapshot images for the agent to inspect, and it can auto-pause on detected failure. It does not say what happens if a print is already running or how a reported failure is communicated back, which keeps it from a 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 numbered workflow is front-loaded and the routing advice follows immediately, so the important content is read first. The trailing Args section largely restates parameter descriptions already present at 100% schema coverage, which is mild redundancy but not harmful.

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 mutating 7-parameter tool with no output schema, the description covers the blocking duration, the returned artifacts (snapshots), and the pause-on-failure behavior, which is most of what an agent needs. Missing are the failure/error path and whether it refuses to run when another job is active.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema carries the defaults and field meanings and the baseline is 3. The description still adds operational meaning by placing the timing parameters in sequence (step 2 wait, step 3 capture, step 4 return) and by clarifying that preview_token is effectively required despite being nullable in the schema.

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 ('Start a print and automatically monitor the first layer') and enumerates the composite behavior in five numbered steps. It explicitly positions itself against start_print and implicitly against monitor_print, so an agent can distinguish it from siblings without opening any 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?

Gives an explicit routing rule: 'Use this instead of start_print when operating autonomously (Level 1/2) to satisfy the first-layer monitoring safety requirement.' It also names the precondition for preview_token (obtained from issue_preview_token, needed beside the user's go-ahead), so the agent knows both when to select this tool and what must precede it.

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

Deploy Server