Skip to main content
Glama

Suggest Loosening

suggest_loosening
Read-only

Identify tolerance links that can be loosened to reduce cost while preserving stack pass rates. Re-verifies each loosening against Monte-Carlo Cpk, keeping nominal unchanged and ranking tightest links first.

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.5/5.0
Behavior5/5

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

Beyond readOnlyHint, the description explains the greedy one-IT-grade algorithm, Monte-Carlo re-verification before each suggestion is committed, mean preservation, ranking by the cost curve, and the exact meaning of ok=False and stopped values. It also enumerates the full return shape, which is very strong behavioral disclosure.

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

Conciseness5/5

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

The description is dense but each sentence earns its place: outcome first, then algorithm, safety verification, refusals, and return contract. The shorthand pointer to tolerance_cost_check for parameter meaning keeps it compact despite having 14 parameters.

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

Completeness5/5

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

Even without an output schema, the description provides a complete return contract including ok, steps, stopped, chain, cost indices, savings, cpk values, spec, and metadata. Combined with readOnlyHint and the explicit refusal semantics, an agent has enough context to invoke and interpret the tool correctly.

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?

With 0% parameter schema coverage, the description must compensate. It usefully documents chain/handle/axis/default_tol/general via reference to tolerance_cost_check and explains spec_min/spec_max defaults and target_cpk/max_steps behavior. However, seed, samples, process, coarsest_it, and step_grades remain unexplained, leaving meaningful tuning parameters undocumented.

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?

The first sentence states the specific outcome: find the loosest tolerance that still passes while maximizing cost savings. It clearly distinguishes the tool from analysis-only siblings like tolerance_stackup and tolerance_cost_check by framing it as the cost-optimizing loosening pass that builds on them.

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?

The description makes the intended use obvious and includes explicit refusal conditions: do not loosen when there is no margin, and do not loosen an already-loosest chain. It lacks an explicit sibling-routing sentence such as 'use X instead when...', but the context is clear enough for an agent to know when this tool applies.

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