fde_distill

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully discloses the primary write side-effect (archiving three artifacts to deliverables/ with a README index), which is meaningful for a generation tool. However, it leaves gaps: no overwrite semantics, no statement of prerequisites or predecessor steps in the pipeline, and no indication of what the tool returns (no output schema exists).

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 dense sentence with zero filler words, but it is poorly structured for agent parsing: it leads with the obscure '引擎五' numbering before any explanatory content, and packs the three output layers into nested parentheticals separated by slashes and colons. The most decision-relevant signal ('跑通'=run after success) is buried mid-sentence. Compact but not front-loaded.

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?

The description thoroughly specifies the output layers and archive location, which is substantial context for a tool with no annotations and no output schema. But it fails to establish this tool's position in the FDE engine sequence among its siblings (fde_interview, fde_classify, fde_quantify, fde_derive, fde_deploy, fde_compose) — an agent cannot reliably infer ordering or prerequisites from the description alone.

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 coverage is 100% — every parameter including nested element fields has a description, so the baseline is 3. The description's '沉淀节点' phrasing maps to the nodes parameter, but the schema itself already says the nodes are '沉淀节点（与 fde_interview 同构）'. The description adds no syntax, format, or behavioral detail beyond what the schema already documents for either parameter.

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 clear verb+resource: 'generate FDE three-layer deliverables' and enumerates the exact output artifacts (document-layer manual, skill-layer template, runtime-layer yaml) plus the archive target (deliverables/ with README index). However, it relies on heavy domain jargon ('引擎五/六', 'Skill 层') and never names a sibling to differentiate from, leaning entirely on the engine-numbering scheme rather than explicit contrast.

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?

Usage context is implied rather than stated: '跑通过程沉淀' implies it runs after a process has been successfully run through, and '引擎六组装用' says the output feeds engine six. But it never explicitly says when to use this versus fde_classify, fde_derive, or fde_deploy, and the input-relationship hint to fde_interview ('与 fde_interview 同构') lives only in the schema, not in the description.

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