Skip to main content
Glama

FAI Report

fai_report
Destructive

Generate AS9102 Rev B Form 3 first-article inspection reports from measurement results, marking each characteristic accepted or rejected against its limits and outputting printable CSV, SVG, or PDF files.

Instructions

First-article inspection report for a drawing page, shaped like AS9102 Rev B Form 3.

Each ballooned characteristic becomes a row carrying the AS9102 fields (Char No. / Reference Location / Characteristic Designator / Requirement / Results / Designed-Qualified Tooling / Nonconformance Number / Notes) plus its limits, the suggested measurement method, and a computed status.

results: balloon number -> measured value; each row is then accepted or rejected against its limits. For a position control you may pass {"x":.., "y":..} and the diametral deviation 2·√(x²+y²) is used, matching gdt_check. Omit it entirely to get a BLANK form for the inspector — every row comes back 'not_evaluated', never a silent pass. path: optionally write the report — .csv (the data), .svg or .pdf (a printable paginated table). part / rev: identity stamped into the file; default to the page's part name and title-block revision. reference: AS9102 field 6 (Reference Location), e.g. the sheet/zone; defaults to the view each characteristic is dimensioned on.

THIS IS NOT A CERTIFIED AS9102 SUBMISSION — it reproduces the Form 3 field layout so a real form can be filled from it, and says so on every artifact it writes.

Returns {ok, columns, rows, summary, disclaimer, part, rev, plan_ok, unmeasurable, path?, size?, format?}; ok=False means at least one characteristic measured out of limits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
revNo
pageYes
partNo
pathNo
ratioNo
resultsNo
referenceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, it discloses non-certification, the ok=false semantics, the 'never a silent pass' invariant, defaulting behavior for part/rev/reference, and supported output formats. These are meaningful behavioral traits not inferable from readOnlyHint/destructiveHint.

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?

Long but information-dense; front-loaded with a one-sentence purpose, then structured parameter details and a clear certification disclaimer. Some field lists and return-object enumeration are verbose, but there is no output schema, so they 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?

For a 7-parameter tool with no output schema and only sparse annotations, this description covers call semantics, return shape, and important caveats. The missing 'ratio' semantics is the main completeness gap.

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?

With 0% schema description coverage, the description compensates well: it explains results (including position-control x/y and omission for a blank form), path formats, part/rev defaults, and reference field meaning. However, the 'ratio' parameter is never explained, so coverage is strong but not total.

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 clearly it produces a first-article inspection report for a drawing page, using AS9102 Rev B Form 3 structure, with row-level evaluation and optional file output. This is a specific, actionable purpose that separates it from generic drawing or inspection tools even without naming 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?

Describes the main workflow (ballooned characteristics become evaluated rows) and the key branch: pass results for measured inspection, omit results for a blank form. It does not explicitly name alternative tools, but gives clear context for when to invoke it.

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