Skip to main content
Glama

Release Package

release_package
Destructive

Creates a deliverable bundle for one item at a revision, combining STEP, drawings, BOM, inspection, and manifest with lifecycle/title-block checks to prevent mismatched output.

Instructions

Produce the vendor/RFQ deliverable bundle for one item at one revision — STEP + drawings + BOM + inspection package + a checksummed manifest — gated by the item's lifecycle state and stamped with its ECO.

Every piece of this exists as its own tool. What this adds is the guarantee that ties them together: the STEP, the PDF, the BOM and the title block all describe the SAME revision of the SAME item. That is the whole point of a release, and it is enforced BEFORE a single file is written:

  • the item must be in a releasable lifecycle state (released), or draft must be set — which watermarks EVERY artifact PRELIMINARY (burned into the drawing, and carried as a format-legal comment in the STEP header, the DXF and the CSVs). An obsolete item is refused in both modes.

  • drawing_gate must pass for every included page — with require_ballooned when the inspection kind is requested.

  • the title block's part number / revision / material must MATCH the items registry. A mismatch is a FAILURE carrying expected-vs-actual, never a silent fix: quietly rewriting the print would destroy the only independent check that it and the model describe the same thing.

A refused release writes NOTHING — no half-populated directory a build script could mistake for a package.

registry / item: the items.json sidecar and the item id being released. out_dir: where the bundle is written (created if absent). kinds: any of "step", "drawing_pdf", "drawing_svg", "drawing_dxf", "bom_csv", "inspection", "manifest_json". Default step/drawing_pdf/drawing_dxf/ bom_csv/manifest_json. manifest_json is always added; inspection (ballooned print + plan + blank AS9102 form) implies a drawing kind. draft: cut a PRELIMINARY package from an unreleased item. rfq: the quote flavour — adds quantity breaks and the cost_estimate rollup as a quote-COMPARISON baseline (fidelity "correlation", band_pct 100 — trust the ratios, not the dollars) and drops internal-only artifacts (the inspection package, which states your acceptance criteria). eco: the change order this release is cut under; defaults to the item's metadata.eco. Stamped into the manifest AND the title block's REV cell. pages: page handles/names/labels (default: every page in the document). handle / object: the geometry to export (default: the first page's main view source — literally the solid the drawing dimensions). process: drawing_gate process ("auto" | "prismatic" | "turned"). density / recursive: BOM options, as in bom_extract. quantity_breaks / cost_process / material: RFQ pricing inputs (default [1, 10, 100], "cnc", and the item's declared material).

Determinism: the same item at the same revision produces a BYTE-IDENTICAL package. The exporters' wall-clock header stamps (the STEP FILE_NAME timestamp above all) are scrubbed to a fixed epoch, so a re-released package is diffable by checksum.

Returns {ok, dir, item, part_number, rev, lifecycle, eco, material, draft, watermark, flavor, kinds, dropped_kinds, implied_kinds, pages, files:[{name, kind, bytes, blake2b}], manifest, manifest_path, verify, problems}. ok=False means the gate refused and nothing was written; each problem carries {code, where, field, expected, actual, reason}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ecoNo
rfqNo
itemYes
draftNo
kindsNo
pagesNo
handleNo
objectNo
densityNo
out_dirYes
processNoauto
materialNo
registryYes
recursiveNo
cost_processNocnc
quantity_breaksNo

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?

Annotations only declare readOnlyHint=false and destructiveHint=true; the description supplies substantial behavioral context beyond that: atomic refusal ('A refused release writes NOTHING'), PRELIMINARY watermarking burned into drawing/STEP header/DXF/CSVs, mismatch failures carrying expected-vs-actual rather than silent fixes, and byte-identical deterministic output with scrubbed timestamps. No contradiction with annotations — both consistently portray a mutating, potentially destructive operation.

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?

Despite its length, every section earns its place: purpose, aggregation rationale, preconditions, parameter block, determinism note, and return shape. Critical scoping and safety statements are front-loaded ('enforced BEFORE a single file is written', 'A refused release writes NOTHING') before the parameter reference list.

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?

With no output schema and minimal annotations, the description carries the full burden and delivers: it enumerates the complete return record including the per-file list {name, kind, bytes, blake2b} and the problem shape {code, where, field, expected, actual, reason}. Nothing an agent needs to invoke or interpret this tool is left undocumented.

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?

Schema description coverage is 0%, yet the description documents essentially all 16 parameters with defaults and semantics: valid kinds and their implication rules, draft/rfq/eco meaning, handle/object defaults ('the solid the drawing dimensions'), and RFQ pricing inputs with defaults [1, 10, 100], 'cnc', and the item's declared material. This fully compensates for the empty schema descriptions.

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 opening sentence names a specific verb and resource: 'Produce the vendor/RFQ deliverable bundle for one item at one revision' with explicit contents (STEP + drawings + BOM + inspection package + checksummed manifest). It further distinguishes itself from siblings by naming its unique addition: 'the guarantee that ties them together' — all artifacts describe the SAME revision of the SAME item.

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?

The description explicitly frames the when-to-use decision: 'Every piece of this exists as its own tool. What this adds is the guarantee that ties them together' — clear differentiation from per-artifact siblings like export_drawing or bom_extract. It also states gating conditions (lifecycle state, drawing_gate pass, title-block match) and refusal modes including obsolete items. However, it stops short of naming explicit decision rules such as 'use the individual exporter when you need only a single artifact'.

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