Skip to main content
Glama

inspection_plan

Build a ballooned inspection plan from a drawing page: dimensions, GD&T frames, and notes mapped to measurement methods by tolerance ratio, flagging features that cannot be inspected as drawn.

Instructions

The characteristic list for a drawing page as data: every dimension, feature control frame, and feature note, ballooned, with nominal, limits, and a suggested measurement method per row.

The method follows the tolerance rather than a guess: the gauge-maker's ratio:1 rule (default 10:1 — the instrument must resolve a tenth of the tolerance band) walked down a per-family instrument ladder, so a loose feature isn't sent to the CMM and a tight bore isn't signed off with a caliper. A bore takes the pin/bore gauge ladder (a micrometer can't reach inside one); a GD&T control referencing a datum frame is CMM work; a datum-free form control is surface-plate work. The required resolution is exact arithmetic, the instrument mapping is shop convention — hence fidelity='correlation'.

Returns {ok, characteristics, count, by_method, unmeasurable, retired, next_balloon, fidelity, band_pct, basis}. ok=False means a characteristic cannot be inspected as drawn — an untoleranced size the inspector has no limits to accept or reject against (code no_tolerance), or a band finer than any instrument on its ladder (code no_instrument) — with unmeasurable naming which and why.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYes
ratioNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses fidelity='correlation', enumerates the failure conditions (ok=False with codes no_tolerance and no_instrument), and names whose characteristics are unmeasurable and why. It also documents the return keys, giving an agent a precise behavioral contract.

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

Conciseness3/5

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

The content is information-dense but overlong and not front-loaded; the opening is a noun phrase rather than a crisp statement of purpose, and method-ladder detail crowds out usage guidance. Several clauses are convoluted, though most sentences ultimately earn their place.

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?

With no output schema, the description helpfully enumerates the return object and its failure semantics, which is what an agent needs to interpret results. The main gap is the undocumented `page` parameter and absent routing guidance versus sibling inspection/report tools.

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?

Schema coverage is 0%, so the description must compensate. It explains the `ratio` parameter thoroughly (the gauge-maker's ratio:1 rule, default 10:1), but the required `page` parameter is left entirely undocumented — no format, identifier, or source is described. Partial compensation only.

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 states a specific resource and scope: a characteristic list for a drawing page, ballooned, with nominal, limits, and a measurement method per row. An agent can tell this apart from siblings like balloon_drawing or fai_report, though it never names them. It lacks an explicit action verb ('build/generate'), making the deliverable clear but the operation implicit.

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

Usage Guidelines2/5

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

There is no when-to-use guidance or comparison to alternatives such as fai_report, balloon_drawing, or drawing_gate. The long passage about gauge ratio and instrument ladders describes internal method selection, not when an agent should pick this tool. Usage must be inferred from 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