AnkusDrive

Overview Schema Source Related Servers Discussions Admin

BOM Extract

bom_extract

Read-only

Extract a bill of materials from a CAD assembly, grouped by source component. Returns counts, volumes, optional mass; can flatten subassemblies or check purchased parts for orderability.

Instructions

Walk an assembly and return [{part, count, total_volume_mm3, total_mass_kg?}, ...] grouped by source (component file + object), NOT the bare object name, so two distinct components both named "Box" don't collapse into one row. density (kg/mm³) is optional.

recursive (default True): descend into linked subassemblies (App::Part) so the BOM flattens to leaf parts. False counts each subassembly as one line.

orderable (default False): opt in to the BUYABILITY view — is every purchased line on this BOM a part that actually exists off the shelf? The default return is unchanged — a bare list — because everything downstream consumes it. With orderable=True you instead get a dict:

rows the same BOM rows, each also carrying designation / standard / part_class plus the catalog verdict (stocked, catalog_code, catalog) consumables purchased parts that are NOT modelled objects and would otherwise never reach a BOM — today the O-ring an oring_groove was cut for, counted across every part that calls for it undesignated purchased rows a buyer cannot order from (no designation) not_stocked rows naming a part nobody stocks, each with a reason and the nearest stocked alternatives designation the full designation_check verdict stocked_count how many purchased lines resolved to a stocked item ok False when anything purchased is undesignated OR not stocked

check_stock=False designates without checking availability. A design built out of fasteners that do not exist is the failure this catches, and the offending rows stay IN the list rather than being quietly dropped. Availability is a curated snapshot of a market (captured, market), not physics.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`density`	No
`assembly`	Yes
`orderable`	No
`recursive`	No
`check_stock`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description discloses substantial behavior beyond the readOnlyHint annotation: the exact return schema, the default bare-list format, the dict shape under orderable=True, and the deliberate choice to keep offending rows in the list rather than silently dropping them. It also notes that availability is a curated snapshot, which is a meaningful caveat.

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?

The description is long but every section earns its place: the core result, grouping rule, parameter semantics, and optional buyability view are each explained with concrete examples. The structure front-loads the primary behavior and then moves through optional modes in a logical order.

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?

Given the tool's complexity, the description is complete: it covers all five parameters, the default and alternate return shapes, edge cases like undesignated/not-stocked rows, and the reason for the default bare-list behavior. Since an output schema exists, returning values need not be re-specified, and nothing essential 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 description coverage is 0%, so the description carries the full burden of explaining parameters. It covers assembly implicitly, density with explicit units, recursive with both True/False behavior, orderable with the resulting dict structure, and check_stock with a concrete example of what skipping availability means.

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 description opens with a precise verb and resource: 'Walk an assembly and return [{part, count, total_volume_mm3, total_mass_kg?}, ...]'. It also clarifies a non-obvious grouping rule ('NOT the bare object name') that distinguishes this from a naive object-name aggregation and from sibling tools like list_assembly_parts.

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 gives clear contextual guidance for each flag: recursive controls flattening, orderable opts into the buyability dict, and check_stock=False skips availability checks. It does not explicitly name an alternative tool or state when not to use bom_extract, but the behavioral conditions for parameter selection are unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server