Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

answer_printer_question

Read-only

Answers one specific hardware question about a selected 3D printer, covering hardware facts, thermal-runaway protection, screw placement during disassembly, or live readings.

Instructions

Answer one question about one printer: a hardware fact, whether it protects against thermal runaway, or which screw goes where when you take an assembly apart.

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_id": "<printer_id>",
      "question": "<question>"
    },
    "name": "answer_printer_question"
  }
}

Input Schema

NameRequiredDescriptionDefault
questionYesOne specific natural-language hardware question.
printer_idYesA printer model id such as ``bambu_a1`` or ``ender3``, or the name a printer is registered under (``default``) for a live reading.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / printer_id / description
      Added value: +"A printer model id such as ``bambu_a1`` or ``ender3``, or the name a printer is registered under (``default``) for a live reading."
    • addedInput schema / properties / question / description
      Added value: +"One specific natural-language hardware question."
  2. Addedv1.5.0

TDQS

A3.9/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the useful constraint that it answers one question about one printer and gives domain examples, but it does not disclose the data source, freshness, authentication needs, or response behavior. With annotations carrying the main behavioral burden, a 3 is appropriate.

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 that states the action, scope, and examples without filler. Every phrase contributes to clarifying what kinds of questions the tool accepts.

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 read-only tool with two required parameters and no output schema, the description is largely complete: it establishes the one-question, one-printer scope and the hardware-question domain. It could be stronger by noting what the answer looks like or any limitations on question complexity, but nothing essential is missing for correct invocation.

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 baseline is 3. The description adds meaningful examples of the question parameter's scope, such as thermal runaway protection and screw placement during assembly, which go beyond the generic schema text. It does not add further detail for printer_id beyond what the schema already explains.

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 states a specific verb and resource: answer one question about one printer. It clarifies the domain with concrete examples such as hardware facts, thermal runaway protection, and screw placement. It does not explicitly distinguish itself from nearby siblings like answer_material_question or troubleshoot_printer, so it falls short of a 5.

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 to use this tool by listing the kinds of single-printer hardware questions it handles. It does not provide explicit exclusions or name alternative tools for broader troubleshooting or material-specific questions, so it is clear but not fully routing-aware.

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