Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

record_hardware_outcome

Records how hardware such as magnets, inserts or screws fit into a printed part, capturing fit, insertion method and notes so each result can be compared against Kiln's planning-time prediction.

Instructions

Record how a piece of hardware in a printed part came out (Pro).

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": {
      "hardware": "<hardware>",
      "result": "<result>"
    },
    "name": "record_hardware_outcome"
  }
}

Input Schema

NameRequiredDescriptionDefault
fitNoHow it went in: dropped_in, needed_pressing or loose_needed_glue. Default: "".
howNo``"after_print"`` (a trap or seat loaded after printing, the default), ``"drop_in"`` (placed at a pause and printed over) or ``"glued"`` (held by adhesive only). Default: "after_print".
stopNoWhich hardware stop of the plan it went in at.
entryNo"top" or "side", if it matters. Default: "".
gradeNoThe part's grade if it has one, e.g. "N52" for a magnet. Default: "".
layerNoThe covering layer index from the plan.
notesNoAnything else you saw. Default: "".
resultYesOne of the results above for that kind.
seat_idNoThe pocket (the plan's seat id, e.g. "S2"). Default: "".
cover_mmNoPlastic over or under it, if you know it.
hardwareYesThe part as the plan named it, e.g. "M3 nyloc".
materialNoThe filament it was printed in. Default: "".
design_idNoThe design, to anchor the report on the plan. Default: "".
predictedNoKiln's verdict for this part at planning time, as the plan printed it (e.g. "at_risk", "margin"), so the record can be judged against it later. Default: "".
printer_idNoThe printer it was printed on. Default: "".
version_idNoThe version that was printed. Default: "".
environmentNoWhere the part lives, e.g. "hot car", "outdoor", "indoor". Default: "".
printer_modelNoThe printer model, e.g. "Bambu Lab A1". Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 schema fields changedv1.5.1
    • addedInput schema / properties / cover_mm / description
      Added value: +"Plastic over or under it, if you know it."
    • changedInput schema / properties / design_id / description
      Previous value: -"Default: \"\"."New value: +"The design, to anchor the report on the plan. Default: \"\"."
    • changedInput schema / properties / entry / description
      Previous value: -"Default: \"\"."New value: +"\"top\" or \"side\", if it matters. Default: \"\"."
    • changedInput schema / properties / environment / description
      Previous value: -"Default: \"\"."New value: +"Where the part lives, e.g. \"hot car\", \"outdoor\", \"indoor\". Default: \"\"."
    • changedInput schema / properties / fit / description
      Previous value: -"Default: \"\"."New value: +"How it went in: dropped_in, needed_pressing or loose_needed_glue. Default: \"\"."
    • changedInput schema / properties / grade / description
      Previous value: -"Default: \"\"."New value: +"The part's grade if it has one, e.g. \"N52\" for a magnet. Default: \"\"."
    • addedInput schema / properties / hardware / description
      Added value: +"The part as the plan named it, e.g. \"M3 nyloc\"."
    • changedInput schema / properties / how / description
      Previous value: -"Default: \"after_print\"."New value: +"``\"after_print\"`` (a trap or seat loaded after printing, the default), ``\"drop_in\"`` (placed at a pause and printed over) or ``\"glued\"`` (held by adhesive only). Default: \"after_print\"."
    • addedInput schema / properties / layer / description
      Added value: +"The covering layer index from the plan."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"\"."New value: +"The filament it was printed in. Default: \"\"."
    • changedInput schema / properties / notes / description
      Previous value: -"Default: \"\"."New value: +"Anything else you saw. Default: \"\"."
    • changedInput schema / properties / predicted / description
      Previous value: -"Default: \"\"."New value: +"Kiln's verdict for this part at planning time, as the plan printed it (e.g. \"at_risk\", \"margin\"), so the record can be judged against it later. Default: \"\"."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"The printer it was printed on. Default: \"\"."
    • changedInput schema / properties / printer_model / description
      Previous value: -"Default: \"\"."New value: +"The printer model, e.g. \"Bambu Lab A1\". Default: \"\"."
    • addedInput schema / properties / result / description
      Added value: +"One of the results above for that kind."
    • changedInput schema / properties / seat_id / description
      Previous value: -"Default: \"\"."New value: +"The pocket (the plan's seat id, e.g. \"S2\"). Default: \"\"."
    • addedInput schema / properties / stop / description
      Added value: +"Which hardware stop of the plan it went in at."
    • changedInput schema / properties / version_id / description
      Previous value: -"Default: \"\"."New value: +"The version that was printed. Default: \"\"."
  2. Addedv1.5.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare a non-destructive, closed-world write, so the description only needs to add what they cannot. The only extra signal is the '(Pro)' tag hinting at a paid-tier gate; nothing is said about side effects, whether re-recording overwrites a prior entry, or how the record is later judged against the 'predicted' value.

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?

A single front-loaded sentence with no filler or repetition. Its brevity is a structural virtue here; the missing information is a completeness problem, not a verbosity one.

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

Completeness2/5

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

For an 18-parameter mutation with no output schema, one sentence is far too thin. It never explains the required fields, the relationship to a print plan (design_id, stop, layer, seat_id), or what the caller gets back, leaving the agent to reverse-engineer intent from field names alone.

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%, so the schema already explains all 18 fields and a baseline of 3 applies. The description adds no parameter meaning at all — notably it never clarifies the required 'hardware' and 'result' pair, and the schema's own 'result' text ('One of the results above for that kind') points at an enumeration absent from both places.

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?

States a specific verb and resource — recording the outcome of a piece of hardware in a printed part — which an agent can understand without opening the schema. However, it does not distinguish itself from near-identical siblings such as record_hardware_insertion, record_magnet_outcome, or record_load_outcome, so the boundary between them is left to inference.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no statement of prerequisites (e.g. that a plan/design must exist first), and no routing to alternatives. An agent cannot tell from this description why it would pick this over record_hardware_insertion or the other record_*_outcome tools.

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