eda_sch_manufacture_data_get_bom_file

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add the return type Promise<File | undefined>, but says nothing about prerequisites, generation side effects, download behavior, or failure cases. The 'returns: BOM 文件数据' line is merely redundant with the signature.

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 compact with no filler — a signature line plus two short phrases. But the human-readable summary is redundant with the tool name, and the structure leads with a dense signature rather than a plain-language statement of what the tool does.

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?

Given 8 semantically opaque parameters, no output schema, no annotations, and a large family of manufacture-data siblings, the description is too thin. The typed signature does not tell an agent what template values are valid, what columns/statistics control, or how the returned File is delivered.

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 schema only documents generic args/windowId wrappers, so the signature is the sole source for the 8 real parameters and their types (fileType 'xlsx'|'csv', filterOptions element shape). This adds meaningful value beyond the schema, but the semantics of filterOptions, statistics, property, columns, and assemblyVariantsConfig are left unexplained, so an agent cannot know how to configure them correctly.

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 includes '获取 BOM 文件' (get BOM file) and a full signature, so an agent can tell it fetches a BOM file from schematic manufacture data. However, the prose is essentially a restatement of the tool name and the signature, and it does not differentiate from siblings such as eda_pcb_manufacture_data_get_bom_file or the template-related eda_sch_manufacture_data_get_bom_templates/get_bom_template_file.

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?

There is no when-to-use guidance whatsoever. The description never addresses selection context or exclusions — no mention of when to pick this over the PCB BOM tool, the BOM template tools, or the other manufacture-data export siblings.

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