Skip to main content
Glama

Standard Part Designate

standard_part_designate
Read-only

Turn non-buyable BOM rows into orderable standard part designations. Normalize, parse, or build specs from fasteners, bearings, orings, and threaded rods.

Instructions

The canonical, orderable designation of a purchased standard part — the string a buyer can actually quote against: "ISO 4762 M4×12 A2", "608-2RS", "AS568-214 NBR70". A BOM row that reads "SocketHeadCapScrew" is not a buyable line; this is what turns it into one.

Three ways in: handle read the designation add_fastener / add_bearing / add_thread stamped on the part when it was built. An object with no stamp reports designation=None plus whether its NAME reads like a purchased part. Nothing is ever inferred from geometry, so a hand-modelled bracket cannot acquire a false designation. designation normalise/parse a string — 'iso4762 m4x12 a2' becomes 'ISO 4762 M4×12 A2', so two spellings of one part can never become two BOM lines. family+spec build one from facts. family is fastener | bearing | oring | threaded_rod, and spec is respectively {kind, size, length, grade} / {designation, seals} / {inner_diameter, cross_section, compound} / {diameter, pitch, length, grade}.

Offline and deterministic — no network, no supplier, no credentials.

Returns the designation card: {ok, family, standard, designation, complete, reason, purchased, ...family-specific fields}. complete=False means the string is not yet enough to order against (typically nobody said which material grade), with reason naming the gap — a missing fact is reported, never defaulted to a plausible-looking lie.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
specNo
familyNo
handleNo
designationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint, the description discloses determinism, offline operation, no credentials, and that missing facts are reported via complete=False/reason rather than defaulted. It also states that unstamped objects report designation=None with name heuristics, adding real behavioral context beyond annotations.

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 organized with short labeled sections. Every sentence adds semantic value, and the core purpose is front-loaded before mode details and return-card behavior.

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 no output schema, the description still explains the return card fields (ok, family, standard, designation, complete, reason, purchased, family-specific) and error/partial-result semantics. Combined with input-mode coverage, an agent has enough to select and invoke the tool correctly.

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?

With 0% schema description coverage, the description fully compensates: it maps handle, designation, and family+spec to concrete meanings, enumerates family values (fastener, bearing, oring, threaded_rod), and specifies the expected spec object fields for each family. Examples clarify string formats.

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 states a specific capability: producing the canonical orderable designation string for a purchased standard part. It uses concrete examples and explicitly contrasts with a non-buyable BOM line, making the tool's function clear and distinguishable from modeling or search siblings.

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?

It clearly documents three invocation modes (handle, designation, family+spec) and when each is appropriate, including a guardrail that geometry is never inferred. It does not explicitly name alternative sibling tools or say when not to use them, so the guidance is context-rich but not fully exclusive.

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