Skip to main content
Glama

Optics Moldability Check

optics_moldability_check
Read-only

Analyze a part's moldability against a pull axis, detecting undercuts, draft violations, and thin-wall risks to flag manufacturing issues before production.

Instructions

Moldability screen for a part against a single pull axis — geometric, no solver. Resolves the model handle's solid, then per face computes the draft relative to pull_axis from the outward normal (draft_deg = 90 − angle(normal, pull); 0 = a wall parallel to the pull that needs draft) and ray-casts the face centroid along ±pull: a face the straight pull frees in neither direction is a re-entrant UNDERCUT (reported with negative draft). Inward chords give a wall- thickness distribution. Scored through the same DfM machinery as dfm_check.

pull_axis: '+z'/'-x'/… or an [x,y,z] vector. process ('injection'|'cnc'| 'sheet'|'fdm') sets the default min wall; override with min_wall_mm.

Returns {process, pull_axis, n_faces, undercut_faces, draft_violations, min_wall_violations, wall_thickness_stats:{min_mm,mean_mm,max_mm,n}, score, pass}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYes
processNoinjection
pull_axisNo+z
min_wall_mmNo
min_draft_degNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the readOnlyHint, the description discloses the algorithm: resolving the solid, per-face draft computation, ray-casting for undercuts, negative draft reporting, and wall-thickness distribution. It also reveals the scoring relationship to dfm_check, giving an agent a concrete model of behavior.

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 every sentence earns its place: the first line summarizes scope, the middle explains behavior, and the final sections document parameters and return shape. It is front-loaded and avoids filler.

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?

It provides full return-shape documentation and algorithm details, which is especially valuable since there is no output schema. The main gap is the omitted min_draft_deg parameter and a lack of error/edge-case notes, but overall an agent can call it 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% schema coverage the description must compensate, and it does for model, pull_axis (including syntax), process values, and min_wall_mm override. However, min_draft_deg is never mentioned, despite being a parameter with a default that directly affects draft_violations, leaving one of five parameters undocumented.

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

Purpose4/5

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

The description names a specific action ('Moldability screen') against a specific resource ('part against a single pull axis') and explains the geometric, non-solver nature. It does not differentiate from the near-sibling moldability_check or explain what makes this the 'optics' variant, so it stops short of full sibling distinction.

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 clear context ('geometric, no solver', 'same DfM machinery as dfm_check') that implies a quick pre-solvability screen. It never states when to prefer this over moldability_check or when a solver-based molding_fill_submit is required, so selection guidance is left to inference.

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