eda-agent

Overview Schema Source Related Servers Discussions Admin

design_bom_file

Generates a consolidated BOM from an Altium .SchDoc or .PrjPcb file on disk without Altium by parsing components offline and grouping designators into purchasable lines by MPN, value, and lib reference.

Instructions

Consolidated BOM from a .SchDoc/.PrjPcb on disk: OFF by default.

Offline FALLBACK, same opt-in as design_review_file. Parses the Altium file directly (no Altium, no license) and groups components into purchasable BOM lines, one per distinct (mpn, value, lib_reference), designators grouped and naturally sorted, quantity summed. A .PrjPcb aggregates all its sheets.

Prefer the live-Altium proj_get_bom / proj_export_bom_html when a session is available. Use this for a file on disk or a CI artifact.

Enable with EDA_AGENT_HEADLESS_REVIEW=1.

Returns {file, line_count, part_count, lines} where each line is {quantity, designators, mpn, manufacturer, value, lib_reference, datasheet}: or {"error": ...} if disabled or unreadable (missing file, a suffix other than .SchDoc/.PrjPcb, or a project whose sheets cannot be resolved). A design read with zero parts adds a warning: an empty BOM is not proof of an empty design.

Input Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

No annotations are provided, so the description carries full burden and does so: it discloses the disabled-by-default gate and how to enable it, that no Altium install/license is required, the exact grouping/aggregation behavior, the error conditions (missing file, wrong suffix, unresolvable project sheets), and the zero-parts warning caveat.

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 key fact (what it does, that it is off by default), and every sentence adds real information. It is dense and somewhat long, with the return-shape block slightly redundant given the output schema exists.

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?

Covers the gating env var, parsing source, aggregation semantics, alternatives, return structure, error modes, and the empty-BOM caveat. Nothing an agent needs to call it correctly is missing, despite the very large sibling surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single 'path' param is undocumented in the schema, but the description compensates by constraining valid inputs to .SchDoc/.PrjPcb files and explaining that a .PrjPcb aggregates all sheets. It stops short of stating whether relative vs absolute paths are accepted.

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?

Opens with a specific verb+resource+source ('Consolidated BOM from a .SchDoc/.PrjPcb on disk'), states the exact grouping key, and explicitly names the siblings it differs from (proj_get_bom / proj_export_bom_html). An agent can differentiate it immediately.

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?

Explicit when-to-use ('Prefer the live-Altium proj_get_bom / proj_export_bom_html when a session is available. Use this for a file on disk or a CI artifact'), plus the opt-in condition via EDA_AGENT_HEADLESS_REVIEW=1 and the OFF-by-default default state.

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

Deploy Server