Skip to main content
Glama

suggest_loosening

Find the loosest tolerance each link can accept to cut cost while the stack still passes a seeded Monte-Carlo Cpk check. Tight links are loosened first, ranked by cost.

Instructions

The loosest tolerance that works: which links can give up tolerance for the biggest cost saving while the stack still passes.

Greedy, one IT grade at a time — every trial loosening is re-verified against tolerance_stackup's seeded Monte-Carlo cpk before it is committed, so nothing it suggests can fail the spec. Candidates are ranked by the tolerance_cost_check curve, so the tightest (most expensive) links get opened first. Loosening preserves each link's MEAN, so the stack's nominal does not move.

Two honest refusals: a chain that does not already meet target_cpk returns ok=False (there is no margin to give away — tighten or re-spec, do not loosen), and an already-loosest chain returns steps=[] with saving=0 rather than inventing a saving. stopped says which: 'no_further_move' | 'max_steps' (re-run on the returned chain to continue) | 'no_margin'.

chain / handle / axis / default_tol / general as in tolerance_cost_check; spec_min/spec_max default to the chain's own worst-case bounds. Returns {ok, steps:[{link, index, from_it, to_it, from_band_mm, to_band_mm, cost_before, cost_after, saving, cpk}], stopped, chain (the loosened scheme), cost_index_before, cost_index_after, saving, saving_pct, cpk_before, cpk_after, target_cpk, spec, note, fidelity, band_pct, basis}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
axisNo+z
seedNo
chainNo
handleNo
generalNom
processNocnc
samplesNo
spec_maxNo
spec_minNo
max_stepsNo
target_cpkNo
coarsest_itNo
default_tolNo
step_gradesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: greedy one-grade-at-a-time iteration, re-verification against a seeded Monte-Carlo cpk before committing, ranking via the cost curve, mean preservation, and two documented refusal paths with their stopped codes. This is unusually complete behavioral disclosure for a mutating/analysis tool.

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?

Front-loads the core purpose, then details mechanics, refusals, and return shape in logical order. Dense and longer than average, but each paragraph carries information; the exhaustive return-field list is justified since no output schema exists.

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

Completeness4/5

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

For a 14-param tool with no annotations and no output schema, it supplies the return shape, the refusal semantics, and the stopped codes, which an agent needs to interpret results. The main gap is the undocumented parameters, which keeps it from being fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 14 parameters, so the description must compensate. It only defers five params by reference ('chain/handle/axis/default_tol/general as in tolerance_cost_check') and explains spec_min/spec_max defaulting; seed, process, samples, coarsest_it, and step_grades remain undocumented in either place.

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

Purpose5/5

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

States a specific verb+resource and goal ('the loosest tolerance that works', links giving up tolerance for cost saving while the stack passes). It names the sibling tools it composes with (tolerance_stackup, tolerance_cost_check), so an agent can distinguish it from them without opening schemas.

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

Usage Guidelines4/5

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

Gives a clear when-not condition ('a chain that does not already meet target_cpk returns ok=False — tighten or re-spec, do not loosen') and points to siblings for the shared parameter vocabulary. It never explicitly states the scenario that should select it over the cost/stackup tools, so it stops short of full alternative routing.

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