szlcsc_altium_review

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

With no annotations provided, the description carries full burden for behavioral disclosure. It clearly states the tool is read-only ('不修改文件'), which is critical behavioral information. It also specifies that it reads already generated reports and summarizes specific warning types (pin/pad/3D placement). This provides sufficient behavioral context for an agent to understand its non-destructive nature.

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 a single, front-loaded sentence that efficiently conveys the tool's purpose, scope, and read-only nature. Every part earns its place: it states what it does (reads, summarizes), for which reports (Altium EasyEDA import), and key constraints (no file modification). No wasted words.

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 the tool has an output schema (which likely describes the return values), the description doesn't need to explain output format. It explicitly addresses input expectations (already generated reports), behavioral constraint (read-only), and scope (pin/pad/3D warnings). The only gap is the unclear parameter semantics, which is already scored separately. Overall, the description is nearly complete for the tool's complexity.

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 0%, meaning the schema provides no description for either parameter. The tool description does not explicitly explain what 'identifier' or 'output_root' mean. However, 'identifier' likely refers to a project or report identifier, and 'output_root' likely specifies where files are stored. Without any parameter info, the baseline is 3; the description adds no value beyond the schema, but the schema itself lacks descriptions.

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 clearly states the specific verb '读取' (read), resource '已生成的 Altium EasyEDA 导入报告', and action '汇总 pin/pad/3D placement 告警'. It distinguishes itself from sibling tools like szlcsc_altium_import (which would create/modify) by explicitly stating it does not modify files, making its purpose unique and unambiguous.

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?

The description implies this tool is for reviewing generated reports, not for creating or modifying them. It does not explicitly state when to use it over alternatives like szlcsc_altium_status or szlcsc_altium_smoke_test, but the focus on 'altium review' and '不修改文件' (no file modification) provides clear context for usage as a read-only review tool.

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