Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

check_ambient_conditions

Read-only

Checks the printer chamber temperature against material-specific limits, warning about unsafe heat, warping risk, or thermal runaway before printing a chosen filament.

Instructions

Check if the printer's chamber temperature is safe for a material.

Reads the current chamber temperature from the connected printer
and checks it against material-specific thermal limits.  Warns
about conditions like:
- Chamber too hot for PLA (softening risk)
- Chamber too cold for ABS/ASA (warping risk)
- Thermal runaway (exceeds printer safety profile max)
- Cool-down advisory after a high-temp print

All checks are local — no data leaves the machine.

Args:
    material: Filament material type (e.g. "PLA", "ABS", "PETG").
              If not provided, only checks against printer max.

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

Input Schema

NameRequiredDescriptionDefault
materialNoFilament material type (e.g. "PLA", "ABS", "PETG"). If not provided, only checks against printer max.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / material / description
      Added value: +"Filament material type (e.g. \"PLA\", \"ABS\", \"PETG\"). If not provided, only checks against printer max."
  2. Changed1 schema field changedv1.5.0
    • removedInput schema / properties / material / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already mark it read-only, non-destructive, and closed-world; the description adds useful specifics: it reads the connected printer's chamber temperature, compares it to material thermal limits, and enumerates warning classes such as PLA softening, ABS/ASA warping, thermal runaway, and cool-down. It also states all checks are local, though it does not cover error behavior or return severity.

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 definition is front-loaded, and the bullet list of warning conditions earns its space by clarifying behavior. The trailing 'Args' block duplicates the input schema, which is unnecessary, but the overall length is modest.

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 simple one-optional-parameter check with read-only annotations and no output schema, the description covers the purpose, local-only behavior, and the material fallback. It stops short of specifying the exact return shape or how warnings are reported, leaving a small gap.

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 coverage is 100% and the only parameter, material, is already documented in the schema with the same optionality and examples. The description repeats that text rather than adding new syntax, accepted values, or format details.

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 ('Check') and resource ('printer's chamber temperature') plus material-specific scope, so the action is clear. It does not explicitly distinguish itself from nearby siblings such as check_material_environment, so it falls short of full sibling differentiation.

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

Usage Guidelines3/5

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

Usage is implied: this is a thermal safety check because it compares current chamber temperature against material limits. It never says when to prefer it over related material/environment checks or when not to call it, so the agent must infer the context.

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