Generate a bill of materials for the active CATIA assembly, listing each distinct part number with quantity, source file, and instances. Use max_depth to control recursion depth.
Build a bill of materials for the active assembly: every distinct part number with its quantity, source file and the instances that use it.
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | Recursion depth. |
Changes observed during successful MCP inspections.
v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is read-only and non-destructive. The description adds meaningful behavior by stating that the tool aggregates distinct part numbers with their quantities, source files, and using instances. It does not discuss depth-limit behavior or error conditions when no active assembly exists, but the safety profile is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one front-loaded sentence with no filler: it states the verb, scope, and output fields immediately. Every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description adequately specifies the returned BOM fields and the active-assembly scope. Minor gaps are the lack of an explanation for what happens with no active assembly and how max_depth affects the final result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter, max_depth, is fully documented in the input schema with its type, default, minimum, maximum, and a description. The tool description adds no additional meaning beyond the schema, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('Build a bill of materials') and a clear scope ('active assembly'), then specifies the output details: distinct part number, quantity, source file, and instances. It is clear enough to distinguish from generic component listing, though it does not explicitly reference sibling tools like catia_list_components or catia_export_bom_csv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of related siblings such as catia_list_components or catia_export_bom_csv. The phrase 'for the active assembly' provides context, but there are no exclusions, prerequisites, or alternative-selection cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.