Scan Excel files for formula errors (#VALUE!, #DIV/0!, #REF!, #NAME?, #NULL!, #NUM!, #N/A) and get grouped counts with locations, including truncation details for large lists.
只扫描公式错误（#VALUE! / #DIV/0! / #REF! / #NAME? / #NULL! / #NUM! / #N/A），不重算。
用途：快速体检现有文件是否有坏公式。 返回 total_errors 与按类型分组的位置明细；位置列表超过 100 条时会 明确说明被截断数量（请以 total_errors 为准，不要以列表长度判断严重程度）。
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full transparency burden and does well: it discloses that the tool only scans (no recalculation), returns total_errors with per-type location details, truncates the location list beyond 100 entries with an explicit truncated-count message, and warns that severity should be judged by total_errors, not list length. It doesn't address edge-case behavior (e.g., empty result format or missing file), which keeps it from a 5.
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 and well-organized: the key differentiator (scan-only, no recalc) is front-loaded in the first line, followed by purpose, then return semantics and truncation warning. Every sentence carries distinct information — error types, no-recalc clause, use case, return structure, and interpretation guidance — with zero waste.
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 there is no output schema, the description appropriately explains the return values (total_errors, grouped location details, truncation count) and how to interpret them correctly. For a single-parameter scan tool with no annotations, this is complete — the agent knows what file to pass, what will be returned, and how to avoid misreading truncated results.
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%, so the description must compensate for file_path. It adds slight meaning by specifying '现有文件' (existing file), implying the target must already exist and is not modified. However, file_path is largely self-explanatory, and the description provides no format, path-type, or validation details, so the compensation is modest.
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 states a specific verb and resource: scan only formula errors, enumerating the exact error types (#VALUE!, #DIV/0!, #REF!, #NAME?, #NULL!, #NUM!, #N/A). It also explicitly distinguishes itself from 'recalculate' with '不重算' (does not recalculate), making its scope unambiguous relative to its siblings.
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 use case is clearly stated: '快速体检现有文件是否有坏公式' (quickly check whether existing files have bad formulas). The '不重算' phrase provides an implicit exclusion against the recalculate sibling, but it doesn't explicitly name alternative tools or state when NOT to use this one, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.