Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

recommend_running_clearance

Read-only

Recommends how much running clearance to model between moving 3D-printed parts, based on mating type, material, printer, and whether printed together.

Instructions

What gap to MODEL between two printed parts that must move.

Needs Kiln 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": {
      "mating": "<mating>"
    },
    "name": "recommend_running_clearance"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNo``"normie"`` (plain English), ``"engineer"`` (full derivation trace), or ``"auto"``. Default: "auto".
briefNoOptional user brief (auto-detects engineer mode).
matingYesWhat is moving against what. ``"pin_in_bore"`` — a pin, shaft or axle turning in a hole; answers a diametral clearance. ``"gear_flank"`` — meshing gear teeth; answers tangential backlash, plus the tooth-thinning and centre-distance forms of the same number. ``"slot"`` — a tongue, rail or key sliding in a groove. ``"planar_face"`` — two flat faces sliding past each other.
materialNoWhat both parts print in (``"PLA"``, ``"PETG"``, ``"ABS"``, ``"ASA"``, ``"Nylon"``, ``"TPU"``). An unrecognised material takes the most conservative row. Default: "PLA".
nominal_mmNoThe feature size, so the answer can be stated in the user's own numbers ("a 6.42 mm bore for a 6 mm pin"). Does not change the recommendation.
printer_idNoThe machine it prints on (e.g. ``"bambu_a1"``). Omit it and the answer still comes — just at the widest band, because an unnamed machine has earned no trust.
same_printNo``True`` (default) when both parts come off one job — a print-in-place mechanism, or both parts on the same plate. ``False`` for separate jobs or two different machines, which widens the allowance because their errors no longer share a machine state. Default: true.
pressure_angle_degNoGear pressure angle; used only for ``mating="gear_flank"``. 20 deg unless the gear says otherwise. Default: 20.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.5.1
    • addedInput schema / properties / brief / description
      Added value: +"Optional user brief (auto-detects engineer mode)."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PLA\"."New value: +"What both parts print in (``\"PLA\"``, ``\"PETG\"``, ``\"ABS\"``, ``\"ASA\"``, ``\"Nylon\"``, ``\"TPU\"``). An unrecognised material takes the most conservative row. Default: \"PLA\"."
    • addedInput schema / properties / mating / description
      Added value: +"What is moving against what. ``\"pin_in_bore\"`` — a pin, shaft or axle turning in a hole; answers a diametral clearance. ``\"gear_flank\"`` — meshing gear teeth; answers tangential backlash, plus the tooth-thinning and centre-distance forms of the same number. ``\"slot\"`` — a tongue, rail or key sliding in a groove. ``\"planar_face\"`` — two flat faces sliding past each other."
    • changedInput schema / properties / mode / description
      Previous value: -"Default: \"auto\"."New value: +"``\"normie\"`` (plain English), ``\"engineer\"`` (full derivation trace), or ``\"auto\"``. Default: \"auto\"."
    • addedInput schema / properties / nominal_mm / description
      Added value: +"The feature size, so the answer can be stated in the user's own numbers (\"a 6.42 mm bore for a 6 mm pin\").  Does not change the recommendation."
    • changedInput schema / properties / pressure_angle_deg / description
      Previous value: -"Default: 20.0."New value: +"Gear pressure angle; used only for ``mating=\"gear_flank\"``.  20 deg unless the gear says otherwise. Default: 20.0."
    • addedInput schema / properties / printer_id / description
      Added value: +"The machine it prints on (e.g. ``\"bambu_a1\"``).  Omit it and the answer still comes — just at the widest band, because an unnamed machine has earned no trust."
    • changedInput schema / properties / same_print / description
      Previous value: -"Default: true."New value: +"``True`` (default) when both parts come off one job — a print-in-place mechanism, or both parts on the same plate.  ``False`` for separate jobs or two different machines, which widens the allowance because their errors no longer share a machine state. Default: true."
  2. Addedv1.5.0

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare this a safe, closed-world read (readOnlyHint true, destructiveHint false, openWorldHint false). The description adds one piece of non-obvious behavior – that Kiln Pro tier is required – but says nothing about how the recommendation is derived (material/printer lookup bands) or what the answer looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short lines with no filler, but the brevity comes at the cost of under-specification rather than efficient information density. The prerequisite is buried in a second line rather than integrated.

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?

With 8 parameters and no output schema, the description should at least indicate what comes back (a clearance number in mm, sometimes backlash and centre-distance forms). It hints at this only obliquely; the schema's mating documentation does most of the explanatory work.

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% and each parameter carries rich documentation (mating modes, material bands, same_print widening). The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys the resource (a running clearance / gap) and the domain (two printed parts that must move), but the phrasing 'What gap to MODEL' is awkward and never states a clean verb like 'recommend'. It does not distinguish itself from near siblings such as check_assembly_clearances or compute_iso_fit.

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?

The only guidance is the gating note 'Needs Kiln Pro', which is genuinely useful, but there is no statement of when to call this versus check_assembly_clearances, compute_iso_fit, or recommend_hole. The agent must infer usage entirely from the schema.

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