Skip to main content
Glama
U-C4N
by U-C4N

Sheet: Draw Parts List

bom_table

Draw an ISO 7573 bill-of-materials item list as a real TABLE entity above the title block, extracting rows from the drawing when none are supplied.

Instructions

Draw the ISO 7573 item list as a real TABLE entity, 180 mm wide (the title-block width), growing upwards from directly above the title block.

With direction="up" the heading row sits against the title block and item 1 is the row above it, so the list extends upwards as parts are added — which is what ISO 7573 asks for on a drawing. Pass rows to draw a list you already have, or omit it and the tool runs bom_extract first. representation reports what was drawn: native (a real ACAD_TABLE on the live engine) or composite (rules and MTEXT headlessly, whose handle is the first child). Refusals: no rows to draw, an unknown column, an unknown direction, a layout that does not exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
at_xNoOverride the anchor X; default is the title block's.
at_yNo
rowsNoRows to draw; omit to extract them from the drawing first.
sizeNoSheet the list is placed on.A3
layoutNo
columnsNo
origin_xNo
origin_yNo
directionNo'up' (ISO 7573 on a drawing: heading at the bottom, items ascending) or 'down'.up
row_heightNo
orientationNolandscape

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only carry destructiveHint=false, so the description carries the burden and does so well: it discloses the two representation modes (native ACAD_TABLE vs composite rules+MTEXT with handle pointing at the first child), the growth direction semantics, and the four refusal cases. That is exactly the non-obvious behavior an agent needs.

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?

Front-loads the core action and size, then branches to direction, rows/omission, representation, and refusals in a compact sequence. The direction sentence partially repeats the schema's own description, which is minor waste but not bloat.

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 an 11-parameter tool with an output schema (so return shape needn't be explained) and thin annotations, it covers the decision-critical pieces: source of rows, orientation behavior, representation output, and refusal modes. Remaining gaps are the anchor/origin parameter semantics.

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 description coverage is only 36% across 11 params, and the description compensates for direction, rows, and columns (via the unknown-column refusal) but says nothing about at_x/at_y, origin_x/origin_y, size, layout, row_height, or orientation. Partial coverage leaves several parameters to be inferred from names alone.

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 and resource ('Draw the ISO 7573 item list as a real TABLE entity'), names the exact geometry (180 mm, title-block width) and placement (above the title block), distinguishing it from sibling bom_extract, which it only invokes as a data source.

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?

Explains the key branch: pass `rows` to draw an existing list, omit it to run bom_extract first, plus when to use direction='up' per ISO 7573. It also enumerates refusal conditions. It does not contrast against other table/annotation siblings (entity_create_table, balloon_add), so it falls short of explicit 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