AnkusDrive

Overview Schema Source Related Servers Discussions Admin

bom_extract

Walk an assembly to generate a bill of materials grouped by source component, optionally flattening subassemblies and checking whether purchased parts are stocked or orderable.

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.9/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: it discloses the default return type, the alternate dict return shape and its fields, that offending rows stay IN the list rather than being dropped, and that availability is a curated market snapshot ('captured', 'market'), not physics. This is exactly the beyond-schema behavioral context 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-loaded with the return contract before the parameter details, and every paragraph maps to a parameter or behavior. It is long and dense, with some detail that could be trimmed, but no sentence is purely redundant.

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 5-parameter tool with an output schema and no annotations, the description covers modes, defaults, return shapes, edge-case handling, and the nature of the stock data. Nothing an agent needs to call 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 description coverage is 0%, so the description must compensate and it does: density is given a unit (kg/mm³) and marked optional, recursive's default and semantic effect are explained, orderable's default and view-switch meaning are explained, and check_stock's effect on designation is stated. Only the required 'assembly' param is left implicit, which is self-evident.

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 concrete verb and resource ('Walk an assembly and return rows grouped by source'), and explicitly disambiguates the grouping key ('component file + object, NOT the bare object name'). An agent can tell what it produces and how it differs from a naive BOM listing without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use guidance for each mode: recursive=True flattens to leaf parts vs False counting subassemblies as one line; orderable=False is the default bare list because everything downstream consumes it, orderable=True opts into the BUYABILITY view; check_stock=False designates without availability checks. The condition selecting each mode is spelled out.

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

Deploy Server