Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

record_hardware_insertion

Record which hardware went into which 3D-printed part, when, and by whom, with lot, serial, photo, and notes for a traceable build history.

Instructions

Record what went into which part, when and by whom (Business).

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

Input Schema

NameRequiredDescriptionDefault
lotNoThe hardware lot or batch, if the shop keeps one. Default: "".
noteNoAnything else worth keeping: "one nut sat proud, reseated". Default: "".
stopNoThe stop number in the plan (1, 2, ...). Leave out for hardware fitted after the print or into a print Kiln did not plan, and say what went in instead.
serialNoThe part's serial or unit number, if the shop keeps one. A first-article inspection draft for that serial (prepopulate_fair_draft) cites the record. Default: "".
hardwareNoWhat went in, when the plan does not say or differs from it: "4x M3 nut". Default: "".
operatorNoWho did it, when it was not the person signed in. Default: "".
design_idNoThe design the part was printed from, so the record sits in its history (optional). Default: "".
photo_pathNoA photo of the hardware in place; Kiln keeps a copy. Default: "".
version_idNoThe design version printed (optional). Default: "".
printer_nameNoThe printer the part is on. Needed with a stop number when more than one printer is registered; for hardware fitted after the print it may be left out. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.5.1
    • changedInput schema / properties / design_id / description
      Previous value: -"Default: \"\"."New value: +"The design the part was printed from, so the record sits in its history (optional). Default: \"\"."
    • changedInput schema / properties / hardware / description
      Previous value: -"Default: \"\"."New value: +"What went in, when the plan does not say or differs from it: \"4x M3 nut\". Default: \"\"."
    • changedInput schema / properties / lot / description
      Previous value: -"Default: \"\"."New value: +"The hardware lot or batch, if the shop keeps one. Default: \"\"."
    • changedInput schema / properties / note / description
      Previous value: -"Default: \"\"."New value: +"Anything else worth keeping: \"one nut sat proud, reseated\". Default: \"\"."
    • changedInput schema / properties / operator / description
      Previous value: -"Default: \"\"."New value: +"Who did it, when it was not the person signed in. Default: \"\"."
    • changedInput schema / properties / photo_path / description
      Previous value: -"Default: \"\"."New value: +"A photo of the hardware in place; Kiln keeps a copy. Default: \"\"."
    • changedInput schema / properties / printer_name / description
      Previous value: -"Default: \"\"."New value: +"The printer the part is on.  Needed with a stop number when more than one printer is registered; for hardware fitted after the print it may be left out. Default: \"\"."
    • changedInput schema / properties / serial / description
      Previous value: -"Default: \"\"."New value: +"The part's serial or unit number, if the shop keeps one. A first-article inspection draft for that serial (prepopulate_fair_draft) cites the record. Default: \"\"."
    • addedInput schema / properties / stop / description
      Added value: +"The stop number in the plan (1, 2, ...).  Leave out for hardware fitted after the print or into a print Kiln did not plan, and say what went in instead."
    • changedInput schema / properties / version_id / description
      Previous value: -"Default: \"\"."New value: +"The design version printed (optional). 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 readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds almost nothing beyond the name: it does not say whether each call creates a new record or merges into an existing one, whether the record is linked into design history, or what happens when a stop number is omitted.

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?

A single front-loaded sentence that gets to the point quickly with no wasted clauses. The unexplained '(Business)' suffix is the only filler and could be dropped without loss.

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

Completeness3/5

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

For a ten-parameter logging tool with no output schema, the schema and annotations carry most of the load, so the short description is not fatal. Still, an agent deciding between recording and planning a hardware insertion, or between this and record_hardware_outcome, gets no help from the description.

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 all ten optional parameters (lot, stop, serial, hardware, operator, design_id, version_id, printer_name, photo_path, note) are already explained in the schema. The description adds no parameter-level meaning beyond the schema baseline, which is acceptable at full coverage.

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 concrete verb and resource: recording what hardware went into which part, plus when and by whom. An agent can tell this is a capture/log operation rather than a planning one. However it never names or contrasts with the obvious sibling plan_hardware_insertion, and the trailing '(Business)' tag conveys nothing actionable.

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 at all: nothing says whether this should be called after plan_hardware_insertion, how it differs from record_hardware_outcome, or whether it is meant per-part or per-stop. The only implicit cue is the parenthetical '(Business)'.

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