Skip to main content
Glama

tolerance_stack_analysis

Read-only

Walk a tolerance chain across a multi-part assembly to quantify gap variation using worst-case, RSS, or Monte Carlo methods.

Instructions

Chain-walking tolerance stack analysis on a multi-part assembly.

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": {
      "chain": "<chain>"
    },
    "name": "tolerance_stack_analysis"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNo"normie" | "engineer" | "auto". Default: "auto".
seedNoMonte Carlo seed for reproducibility. Default: 42.
briefNoOptional user brief (auto-detects engineer mode).
chainYesList of part dicts. Each part: {"name": "...", "nominal_mm": float, "tol_plus_mm": float, "tol_minus_mm": float, "axis": "xy"|"z", "direction": +1|-1, "distribution": "normal"|"shifted_normal"|"uniform"}.
methodNo"worst_case" (default; arithmetic sum, safest for safety-relevant gaps), "naive_rss", "bender_rss", "scholz_mean_shift", or "monte_carlo" (uses ``seed``, ``n_samples``, ``fdm_aware``). Default: "worst_case".
materialNoMaterial id (only consulted when ``printer_id`` is set; together they look up calibration).
fdm_awareNoWhen method="monte_carlo", treat a printed part's height (Z) as less certain than its X/Y, as measured prints show. How much less follows the printer's calibration tier when printer_id is set. Default: true.
n_samplesNoMonte Carlo sample count. Default: 10000.
printer_idNoPrinter identifier (e.g. "bambu_a1") to look up calibration for. When supplied alongside ``material``, the result's confidence_warning notes the calibration tier — HIGH tightens the implied bound, LOW/UNKNOWN points the user at the slicer's flow-rate wizard.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.5.1
    • addedInput schema / properties / brief / description
      Added value: +"Optional user brief (auto-detects engineer mode)."
    • addedInput schema / properties / chain / description
      Added value: +"List of part dicts.  Each part: {\"name\": \"...\", \"nominal_mm\": float, \"tol_plus_mm\": float, \"tol_minus_mm\": float, \"axis\": \"xy\"|\"z\", \"direction\": +1|-1, \"distribution\": \"normal\"|\"shifted_normal\"|\"uniform\"}."
    • changedInput schema / properties / fdm_aware / description
      Previous value: -"Default: true."New value: +"When method=\"monte_carlo\", treat a printed part's height (Z) as less certain than its X/Y, as measured prints show.  How much less follows the printer's calibration tier when printer_id is set. Default: true."
    • addedInput schema / properties / material / description
      Added value: +"Material id (only consulted when ``printer_id`` is set; together they look up calibration)."
    • changedInput schema / properties / method / description
      Previous value: -"Default: \"worst_case\"."New value: +"\"worst_case\" (default; arithmetic sum, safest for safety-relevant gaps), \"naive_rss\", \"bender_rss\", \"scholz_mean_shift\", or \"monte_carlo\" (uses ``seed``, ``n_samples``, ``fdm_aware``). Default: \"worst_case\"."
    • changedInput schema / properties / mode / description
      Previous value: -"Default: \"auto\"."New value: +"\"normie\" | \"engineer\" | \"auto\". Default: \"auto\"."
    • changedInput schema / properties / n_samples / description
      Previous value: -"Default: 10000."New value: +"Monte Carlo sample count. Default: 10000."
    • addedInput schema / properties / printer_id / description
      Added value: +"Printer identifier (e.g. \"bambu_a1\") to look up calibration for.  When supplied alongside ``material``, the result's confidence_warning notes the calibration tier — HIGH tightens the implied bound, LOW/UNKNOWN points the user at the slicer's flow-rate wizard."
    • changedInput schema / properties / seed / description
      Previous value: -"Default: 42."New value: +"Monte Carlo seed for reproducibility. Default: 42."
  2. Addedv1.5.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful non-annotation fact — the Kiln Pro tier requirement — but says nothing about output shape, whether results are deterministic aside from the seed, or what confidence_warning means beyond the schema's own notes.

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?

Two short lines with the purpose front-loaded and the entitlement constraint immediately after; nothing is wasted. It is arguably too terse for a nine-parameter analytical tool, but nothing in it is filler.

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?

The rich schema compensates for most of the thin description, and annotations cover safety. However, this is a numerical analysis tool with no output schema, and the description gives no hint about what the analysis returns (worst-case gap, RSS bounds, pass/fail), leaving a real gap for an agent deciding whether to call it.

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 the schema itself elaborates the chain part dict structure, method options, fdm_aware semantics, and defaults. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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 names a specific operation on a specific resource: 'chain-walking tolerance stack analysis on a multi-part assembly.' No sibling tool in the list performs tolerance stack analysis, so it is distinguishable, but the definition never explicitly positions itself against related tools like validate_assembly or check_assembly_clearances.

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 exclusions, and no mention of alternatives such as which tool to call if the assembly is not yet validated. The only contextual cue is the entitlement note 'Needs Kiln Pro,' which gates access but does not tell an agent when this analysis is the right call.

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