Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

record_load_outcome

Record real-world load outcomes for 3D-printed parts—material, result (held, sagged, broke), and days in service—to validate designs and track reliability.

Instructions

Report how a printed part did under a load it carried in real use.

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": {
      "material": "<material>",
      "result": "<result>",
      "days_in_service": "<days_in_service>"
    },
    "name": "record_load_outcome"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNoAnything else you saw. Default: "".
load_nNoThe load in newtons, if known.
resultYesheld, sagged or broke.
verdictNoWhat design_for_load said: holds, not_safe, not_vouched or unmeasured; leave empty if it was not asked. Default: "".
hardwareNoWhat the part carried besides the load: items like {"name": "PCB", "mass_g": 30, "count": 1}, mass per piece in grams (design_for_load's ``record_with`` anchor carries the list it counted). Kept with the report in words; an item with no mass that is not a name Kiln knows a typical weight for is refused.
materialYesThe filament it was printed in, e.g. "PLA", "PETG", "bambu_pa6_cf".
design_idNoThe design, if it has one in Kiln. Default: "".
printer_idNoThe printer it was printed on. Default: "".
version_idNoThe version that was printed. Default: "".
environmentNoWhere the part lives, e.g. "garage shelf", "hot car", "outdoor". Default: "".
conditioningNoFor nylon: dry or conditioned; leave empty if you do not know. Default: "".
printer_modelNoThe printer model, e.g. "Bambu Lab A1". Default: "".
load_knowledgeNoHow you know the load: measured, estimated or guessed. Default: "estimated".
days_in_serviceYesDays the part had carried its load when you looked.
stress_fractionNoThe creep stress fraction design_for_load reported, if it was asked.
service_temperature_cNoThe temperature it lives at; leave out for room temperature.
temperature_knowledgeNomeasured, estimated or guessed. Default: "estimated".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed17 schema fields changedv1.5.1
    • changedInput schema / properties / conditioning / description
      Previous value: -"Default: \"\"."New value: +"For nylon: dry or conditioned; leave empty if you do not know. Default: \"\"."
    • addedInput schema / properties / days_in_service / description
      Added value: +"Days the part had carried its load when you looked."
    • changedInput schema / properties / design_id / description
      Previous value: -"Default: \"\"."New value: +"The design, if it has one in Kiln. Default: \"\"."
    • changedInput schema / properties / environment / description
      Previous value: -"Default: \"\"."New value: +"Where the part lives, e.g. \"garage shelf\", \"hot car\", \"outdoor\". Default: \"\"."
    • addedInput schema / properties / hardware / description
      Added value: +"What the part carried besides the load: items like {\"name\": \"PCB\", \"mass_g\": 30, \"count\": 1}, mass per piece in grams (design_for_load's ``record_with`` anchor carries the list it counted). Kept with the report in words; an item with no mass that is not a name Kiln knows a typical weight for is refused."
    • changedInput schema / properties / load_knowledge / description
      Previous value: -"Default: \"estimated\"."New value: +"How you know the load: measured, estimated or guessed. Default: \"estimated\"."
    • addedInput schema / properties / load_n / description
      Added value: +"The load in newtons, if known."
    • addedInput schema / properties / material / description
      Added value: +"The filament it was printed in, e.g. \"PLA\", \"PETG\", \"bambu_pa6_cf\"."
    • changedInput schema / properties / notes / description
      Previous value: -"Default: \"\"."New value: +"Anything else you saw. 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: +"held, sagged or broke."
    • addedInput schema / properties / service_temperature_c / description
      Added value: +"The temperature it lives at; leave out for room temperature."
    • addedInput schema / properties / stress_fraction / description
      Added value: +"The creep stress fraction design_for_load reported, if it was asked."
    • changedInput schema / properties / temperature_knowledge / description
      Previous value: -"Default: \"estimated\"."New value: +"measured, estimated or guessed. Default: \"estimated\"."
    • changedInput schema / properties / verdict / description
      Previous value: -"Default: \"\"."New value: +"What design_for_load said: holds, not_safe, not_vouched or unmeasured; leave empty if it was not asked. Default: \"\"."
    • 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 state readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the agent knows this is a local, non-destructive write; the description is consistent with that but adds nothing. It never says where the report is persisted, whether it attaches to a design/passport, whether repeat reports overwrite or accumulate, or that certain hardware entries are refused — all behavior an agent would want before committing a record.

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 with no filler or redundancy. It is efficient, though for a 17-parameter tool the terseness borders on under-specification rather than genuine concision.

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?

With 17 parameters, a chain of cross-references to design_for_load (verdict, stress_fraction, hardware record_with anchor), and no output schema, the description is far too thin to be self-sufficient. It should at minimum explain that fields like verdict and stress_fraction are backfilled from a prior design_for_load call and what linking identifiers (design_id, version_id, printer_id) buy the agent.

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% across all 17 parameters, so the schema already carries the meaning of material, result, days_in_service, verdict, stress_fraction and the knowledge/provenance fields. The description adds no syntax, defaults, or cross-field constraints beyond that, which is the expected baseline for a fully documented schema.

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 gives a specific verb ('Report') and a specific resource ('how a printed part did under a load it carried in real use'), so an agent knows this captures real-world service outcomes rather than test-bench data. It does not, however, distinguish this from nearby siblings such as record_print_outcome or design_for_load, which the schema references but the prose never mentions.

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 explicit when-to-use or when-not-to-use guidance, and no mention of the alternative tools (design_for_load for prospective assessment, record_print_outcome for print-level results). The only signal is the implicit 'real use' framing, which a reader must infer means 'call after the part has been in service.'

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