easyeda_export_manufacturing

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

Beyond the annotations, the description discloses real behavioral traits: the project is not modified or saved, no order is placed, and the tool self-verifies bytes, SHA256 and ZIP CRC, while final manufacturing correctness still needs visual preview. That is meaningful extra context. Minor tension: annotations declare destructiveHint=true and readOnlyHint=false while the text emphasizes non-modification, though writing new files does explain the write hint.

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?

A single dense sentence with the purpose front-loaded and the safety constraints appended, followed by the verification caveat. No filler, though the semicolon-heavy packing makes it slightly harder to scan.

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?

With an output schema present, return-value details are already covered, and the description supplies the essential framing: what it produces, where, and that it is non-destructive to the project. It omits overwrite behavior for existing files and failure modes, which would round it out.

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?

Schema description coverage is 100% and each parameter carries its own explanation (prefix default Board, document_uuid from inspect_project, session ID from session.list, destination relative to --output-root). The description adds nothing beyond echoing --output-root, so the baseline 3 is correct.

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 verb (导出/export) and the exact artifacts produced (Gerber ZIP、BOM CSV、贴片坐标 CSV), plus the destination scope (--output-root 内新文件). This clearly distinguishes it from sibling inspect/drc/netlist tools that read rather than emit manufacturing files.

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?

It rules out two things explicitly (不修改/保存工程、不下单) and hints that preview is still required for correctness, which is useful context. However, it never says when to prefer this over, say, easyeda_check_drc or easyeda_inspect_project first, nor does it state the precondition that document_uuid must come from inspect_project (that detail lives only in the schema).

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