Skip to main content
Glama

release_package

Build a vendor/RFQ deliverable bundle for one item revision—STEP, drawings, BOM, inspection, and manifest—gated by lifecycle state and ECO, with all files matching that revision. Refuses mismatch.

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.7/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 thoroughly: refusal semantics ('A refused release writes NOTHING'), the PRELIMINARY watermarking behavior of draft mode, title-block mismatch as a hard failure with expected-vs-actual rather than a silent fix, byte-identical determinism with scrubbed timestamps, and the failure shape of `problems`.

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?

The purpose is front-loaded in the first line, gates are bulleted, and parameters are grouped in a scannable list. Given 16 parameters the length is largely justified, though a few sentences (e.g. the 'no half-populated directory a build script could mistake for a package' aside) are more colorful than necessary.

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?

For a high-complexity, 16-parameter tool with no output schema and no annotations, the description still supplies the return contract ({ok, dir, ..., problems} with per-problem fields), the failure modes, and the determinism guarantee. Nothing an agent needs to invoke or interpret it correctly is missing.

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 coverage is 0% across 16 parameters, yet the description documents essentially every one — registry/item/out_dir, kinds with defaults plus the always-added manifest and inspection implication, draft, rfq, eco defaulting to item metadata, pages, handle/object defaults, process, density/recursive cross-referencing bom_extract, and quantity_breaks/cost_process/material defaults. 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?

States a specific verb+resource ('Produce the vendor/RFQ deliverable bundle for one item at one revision') and enumerates the exact artifacts included. It explicitly distinguishes itself from siblings by noting 'Every piece of this exists as its own tool' and names the added value: the revision-consistency guarantee across STEP/PDF/BOM/title block.

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?

Gives clear conditions: the item must be `released` or `draft` must be set, and `obsolete` is refused in both modes. It also explains when to pick `draft` and `rfq` flavors. It stops short of explicitly routing the agent to the single-artifact siblings (e.g. 'use export_drawing if you only want a PDF'), so it is clear context rather than full when/when-not/alternatives.

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