Skip to main content
Glama

seal_check

Rates O-ring glands by checking squeeze and fill percentages against static or dynamic limits, returning pass/fail.

Instructions

Rate an O-ring gland (pairs with oring_groove): squeeze=W-depth, fill= (pi/4 W^2)/(width*depth). Squeeze must sit in the application band (static 15-30%, dynamic 10-20%), fill below max_gland_fill_pct. Returns {squeeze_mm, squeeze_pct, gland_fill_pct, squeeze_range_pct, within_squeeze, within_fill, pass}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
applicationNostatic_radial
groove_depth_mmYes
groove_width_mmYes
max_gland_fill_pctNo
cross_section_dia_mmYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose the computation (squeeze=W-depth, fill formula), the pass criteria, and the exact return fields, implying a deterministic read-only check. It stops short of explicitly confirming no side effects, but the behavioral picture is largely clear.

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?

Dense but well front-loaded: purpose, formula, acceptance criteria, then return shape. Nearly every clause earns its place, though the notation is terse enough to require careful reading.

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?

There is no output schema, but the description enumerates the returned fields (squeeze_mm, squeeze_pct, gland_fill_pct, squeeze_range_pct, within_* flags, pass), which is enough to interpret results. Only the application-selection semantics remain slightly under-specified.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate; it explains the squeeze/fill relationships, the meaning of max_gland_fill_pct as a threshold, and supplies valid 'application' bands. It falls short of mapping symbols to exact parameter names like cross_section_dia_mm or groove_depth_mm.

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 and resource ('Rate an O-ring gland') and explicitly names the sibling it pairs with ('pairs with oring_groove'), letting an agent distinguish it from groove-creation tools without opening the schema.

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

Usage Guidelines3/5

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

It gives the acceptance bands (static 15-30%, dynamic 10-20%) and mentions pairing with oring_groove, which implies context, but it never states when to call this versus alternatives or what prerequisites (e.g. an existing groove) must hold.

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