Skip to main content
Glama

O-Ring Groove

oring_groove

Calculate standard static O-ring gland dimensions from wire cross-section and ID, then cut the annular groove into a flat face for a proper seal.

Instructions

Compute a static O-ring gland (groove) and optionally cut it into a face.

This is the gland calc designers always fumble, plus an optional cut. Given the O-ring cross-section it returns standard static-seal gland dimensions; with cut=True it also machines the annular groove into a flat face.

cross_section: O-ring wire cross-section diameter in mm (e.g. 1.78, 2.62). Required, > 0. inner_diameter: groove inner diameter in mm (the O-ring's nominal seal ID). Required when cut=True; used to size the returned diameters either way. handle: host solid to cut into (required only when cut=True). face: the flat face to cut the groove into — a stable f_* tag (preferred), a 'FaceN' index string, or an int. Required when cut=True. Must be planar. gland_type: seal-geometry label, default 'static_radial' (informational). compound: optional elastomer + durometer the RING is ordered in ("NBR70", "FKM75", "EPDM70"). Changes no geometry; it completes the AS568 designation of the ring itself — the purchased part this groove exists to hold, which no BOM would otherwise contain because the ring is never a modelled object. cut: True (default) cuts the groove and returns a new solid; False makes this a pure calculator (no geometry, no handle). name: name for the resulting solid when cut=True.

Gland rule (static seal): groove_depth = cross_section0.75 (~25% squeeze, clamped to a 20-30% band), groove_width = cross_section1.30. The groove's inner diameter equals inner_diameter and it spans outward by groove_width.

Returns {groove_depth, groove_width, groove_inner_diameter, groove_outer_diameter, squeeze_pct, cross_section, gland_type, oring} (all mm except squeeze_pct in percent). When cut=True it ALSO returns {handle, name, volume} for the grooved solid; the host input is hidden. mating numbers: cut a groove of inner_diameter to seat an O-ring of that ID; groove_outer_diameter sizes the radial space the groove occupies. oring is the RING's designation card ("AS568-214 NBR70"), or ok=False naming the nearest tabulated sizes when the gland is not an AS568 standard size — an off-table ring is a custom tooled part, and saying so beats naming a dash number that will not seal. oring_catalog is the ring's off-the-shelf verdict.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cutNo
faceNo
nameNoORingGroove
handleNo
compoundNo
gland_typeNostatic_radial
cross_sectionYes
inner_diameterNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only provide readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description goes well beyond these by detailing the exact mathematical formulas for groove dimensions, the clamping rule, the return structure, and the meaning of the 'oring' field. It clarifies that cut=True returns a new solid and hides the host input, explaining side effects. No contradiction with annotations.

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?

The description is well-structured, starting with the core purpose, then parameter details, then return values. It is verbose but each paragraph earns its place, explaining complex behavior. A minor deduction for the informal aside 'designers always fumble' and some redundancy in explaining cut in both the parameter list and behavior section, but overall it remains focused and readable.

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?

Given the tool's complexity (8 parameters, dual modes, rich return types) and lack of output schema, the description covers all necessary information: formulas, return fields, cut behavior, and special edge cases like non-AS568 rings. It is comprehensive enough for an agent to use the tool correctly without additional documentation.

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

Parameters5/5

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

Since schema description coverage is 0%, the description is the sole source of parameter meaning. It provides extensive details for all 8 parameters: units, constraints, required conditions, examples, and semantic roles (e.g., compound doesn't affect geometry). It fully compensates for the schema gap, adding value far beyond the raw JSON schema.

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 description clearly states the tool computes a static O-ring gland and optionally cuts it into a face. It uses specific verbs and resources ('compute', 'cut', 'gland', 'groove') and distinguishes from other tools by its focus on O-ring seals, a unique niche among siblings. The purpose is unambiguous and not a tautology.

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 provides clear context on when to use cut=True vs False, and when inner_diameter is required. It explains the dual calculator/geometry modes. However, it does not explicitly name any alternative tools or provide 'when not to use' guidance, so it falls short of a 5 but is solid for context.

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