Calculates annual cost savings and ROI from salary, AI takeover ratio, and investment data, then ranks results descending and writes quantification.json for automated decision support.
FDE 量化四字段 + ROI 排序（引擎三）——年节省=岗位年薪×AI接管工时占比（GUIDE §4.3，与 train_report 同公式同源）；ROI=年节省÷(投入+1) 降序，落 quantification.json（若引擎二已跑自动关联判定标签）。
| Name | Required | Description | Default |
|---|---|---|---|
| nodes | Yes | 量化入参（岗位口径） | |
| enterprise_id | Yes | 🔴 企业标识 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses a file write side effect (quantification.json), a conditional behavior (auto-associating labels when engine two has run), and the exact calculation formula. It does not cover all possible side effects, but it provides meaningful behavioral transparency beyond a simple verb.
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 dense single sentence, front-loaded with the core purpose and followed by formula, output, and conditional behavior. It contains no fluff, though the heavy technical density could be slightly clearer with more explicit segmentation.
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?
For a computation tool with full parameter schema coverage and no output schema, the description is fairly complete: it states inputs, formula, output artifact, and an important conditional label-association behavior. It does not describe the return payload, but the tool's primary artifact is the file it writes, which is disclosed.
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%, so the baseline is 3. The description adds value by explaining how parameters relate: annual_salary multiplies takeover_ratio, and one_time_investment enters the ROI denominator with a +1 guard. This goes beyond the schema's individual field 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 states a specific computation and output goal: quantify FDE four fields, compute annual savings via a salary × takeover-ratio formula, and sort by ROI. It distinguishes itself from siblings by labeling itself as engine three and explicitly tying its formula to train_report, so an agent can tell it apart.
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 clearly positions the tool in a pipeline ('engine three') and notes a precondition: if engine two has already run, diagnosis labels are automatically associated. It does not explicitly name alternatives or when-not-to-use conditions, but the sequential context gives clear enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.