novel-mcp · Chinese Web Novel Writing System

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

No annotations are provided, so the description carries the full burden. The description mentions what it analyzes (conflicts, sentence distribution, hook position) but doesn't disclose what the output looks like (no output schema), whether any side effects occur, or any behavioral traits like needing certain text length. It's a read-only analysis, but that's not stated. Given missing annotationscrazy, a 2 is appropriate.

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 sentence, concise and front-loaded with the purpose. It efficiently lists three specific aspects it checks. 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?

For a single-parameter analysis tool with no output schema and no annotations, the description covers the core function but lacks details on what the output format is, how to interpret results, or edge cases. The tool is relatively simple, but given no explicit return info, it's minimally adequate. The lack of guidance on when to use it vs. sibling tools also reduces completeness.

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% for the single parameter 'chapter_text', which has a clear description including a suggested minimum length. The tool description itself doesn't add any parameter semantics beyond what the schema provides, but since the schema is fully descriptive, baseline 3 applies.

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 the tool analyzes chapter rhythm and lists specific aspects: conflicts in the first 300 characters, distribution of long/short sentences, and hook position. This is a clear verb+resource with specific scope. It doesn't explicitly distinguish from siblings like check_rhythm_compliance or conway_outline_rhythm_tool, but the specific focus on chapter text rhythm is clear enough.

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?

No when-to-use or when-not-to-use guidance is provided. There are sibling tools like check_rhythm_compliance and conway_outline_rhythm_tool that might overlap, but the description doesn't clarify when to choose this over them. The context signals show one parameter (chapter_text), but the description doesn't mention prerequisites like minimum length (though the schema suggests at least 1500 characters).

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

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

无 annotations 提供，描述完全承担行为透明度责任。描述说明输出为'章卡骨架'并列出六个要素，但未披露行为特征：例如是否覆盖已有章卡、是否需要先有项目上下文（high_concept 是必填，但 genre 有默认值）、是否异步执行（与 batch_ 前缀相关的写入行为）、是否有批量限制（章节区间大小）或失败时局部成功的可能性。作为生成/写入类工具，行为细节严重不足。

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?

单句描述，紧凑且信息密度高，列出了核心输出要素，无冗余。唯一不足是未分段或扩展用法，但简洁性本身尚可。

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?

工具复杂度中等（批量生成、4参数、无输出schema），但描述仅覆盖了目的，未讨论：输出格式（章卡骨架的具体结构）、写入行为（是否持久化、是否覆盖）、前置依赖（必须要有 high_concept 和明确的章节区间，但无project上下文要求）、失败处理（批量部分失败如何返回）。由于无 annotations 和 output schema，描述应承担更多责任，但实际缺口大。

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 描述覆盖率为 75%（high_concept、ch_start、ch_end 均有描述；genre 有枚举但无描述），描述未额外解释参数语义。high_concept 的概念清楚，但 genre 的默认值和枚举作用未在描述中说明。描述提及'为指定章节区间'，与 ch_start/ch_end 对应，但未增加超出 schema 的含义，故维持基线3。

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?

描述使用明确的动词（批量生成）与资源（章卡骨架），并列出生成的具体要素（核心冲突/节奏位置/爽感预算/情绪目标/章末钩子/伏笔），清晰区分于兄弟工具如 analyze_chapter_rhythm 或 check_rhythm_compliance。虽未明确说明区别于 validate_outline_batch 等验证类工具，但整体目的明确。

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?

描述未提供何时使用此工具 vs 替代工具的指导。没有说明前置条件（如必须已初始化小说项目、已存在大纲或高概念），也没有提及与 write_chapters_async 或 validate_outline_batch 的分工。仅暗示用于'指定章节区间'生成骨架，但无明确使用时机或排除条件。

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

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

With no annotations, the description carries the full transparency burden. It discloses key behavioral variance: local version actually cancels, while edge version returns guidance instead of performing the cancellation. This is useful, though it does not mention error handling or side effects beyond those two settings.

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 extremely compact—two short Chinese clauses—and every sentence contributes meaningful information: what it does and how behavior differs by environment. There is no padding or redundancy.

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 single-parameter cancellation tool, this is reasonably complete: it identifies the action, resource, and version-specific behavior. The only minor gap is that it does not specify the content or format of the '指引' returned by the edge version, but that may be intentionally opaque.

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% for the single parameter job_id, which is described as the async task ID. The description adds no additional parameter meaning, but the schema already fully documents the parameter, so the baseline of 3 is appropriate.

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 explicitly states the tool cancels an asynchronous writing task, with a specific verb and resource. It also differentiates between local and edge behavior, making its purpose clear and distinct from sibling tools like write_chapters_async and get_write_status.

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 intended context is implied—use it to cancel an async writing job—but there is no explicit guidance on when to use it versus alternatives, nor any prerequisites like checking status first. The local/edge distinction adds behavioral context, not usage direction.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It mentions checking 'item by item' but does not explain what items are checked, how results are returned, whether it mutates anything, or any side effects. The description is too minimal to convey the tool's operational behavior.

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 concise sentence, front-loaded with the core purpose. It avoids verbosity but sacrifices useful details like output format or expected behavior. Given its brevity, it is appropriately sized, though more content would improve it.

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 tool has a simple interface (2 params, 1 required, no output schema). Without an output schema, the description should explain what results look like or what users can expect. It only states 'check item by item' with no indication of return values, error handling, or how compliance is reported. This is incomplete for a tool that presumably returns a detailed report or pass/fail status.

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 50% (only chapter_text has a Chinese description '章节正文'). The description adds no further meaning to parameters beyond what the schema provides—it does not explain how platform values map to different rhythm requirements or how chapter_text is processed. Baseline 3 is appropriate, but the description fails to compensate for the undocumented platform 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 clearly states the tool's purpose: checking rhythm compliance against specific platform requirements (Tomato, Qidian, Feilu). The verb 'check' and resource 'rhythm compliance' are specific, and the mention of platforms distinguishes it from sibling tools like analyze_chapter_rhythm.

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 the tool is used for compliance checking but does not explicitly state when to use it versus alternatives like analyze_chapter_rhythm or conway_outline_rhythm_tool. No when-not-to-use guidance or alternative references are provided.

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

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

No annotations provided, so description carries full burden. It states the tool gives adaptation advice without describing side effects, prerequisites, or limitations. For an advisory tool this is minimally acceptable but lacks behavioral detail.

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?

Single sentence, front-loaded with purpose, no filler. Efficient but could list how the advice is structured.

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?

No output schema and no annotations. Description only gives a high-level promise of platform advice, omitting details like whether it returns a comparison report, how the genre parameter influences advice, and what the response format looks like. For a two-parameter tool with zero schema coverage, this is sparse.

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 0%, description must compensate. The description mentions three platforms (matching the enum) and lists aspects like 读者画像/节奏/爽点偏好/禁忌, but does not explain the 'genre' parameter or how it affects the advice beyond a default value.

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?

Description clearly states the tool provides platform adaptation advice for three Chinese web novel platforms (Tomato, Qidian, Feilu), covering tonal differences in reader profiles, pacing, and taboo topics. The verb

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?

No guidance on when to use this vs alternatives like coach_strategy_template or analyze_chapter_rhythm. The description implies usage for platform adaptation but lacks explicit contextual triggers or exclusions.

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

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

No annotations are present, so the description bears full responsibility for disclosing behavioral traits. It only states that it 'generates' a skeleton, but does not explain side effects, whether it requires any prior state (like an initialized project), or if it's read-only. The listed output components hint at the structure but omit details on how the output is delivered or whether it alters any data. This is minimal transparency for a tool without annotations.

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 delivers the core purpose and output components efficiently. There is no wasted words or repetition. However, it could benefit from a more structured layout (e.g., bullet points) to improve scannability, but for a one-liner it's appropriately concise.

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?

This tool appears to be part of a larger strategy workflow (given siblings like coach_platform_adapt, plan_volume_arc). The description does not explain how this skeleton integrates with other tools, what the output looks like (no output schema), or the expected depth of the strategy book. With no output schema and minimal behavioral info, the description is incomplete for an agent to fully understand the tool's scope and output format.

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 only 25% (only high_concept has a description). The description mentions '高概念/题材/平台' which maps to high_concept, genre, and platform, but adds no extra meaning beyond the schema. It does not explain how these parameters influence the output, nor does it clarify defaults like target_word_count. Given low coverage, the description should compensate with parameter details, but it fails to do so.

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 tool's function: generating a creation strategy book skeleton based on high concept, genre, and platform. It lists the components (题材分析/爽点架构/节奏规划/平台适配/风险提示), providing a specific resource and action. However, it does not differentiate from siblings like coach_platform_adapt, which also focuses on platform adaptation, so it lacks that explicit distinguishing clarity.

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 provides no guidance on when to use this tool versus alternatives. It simply describes what it does without suggesting context, prerequisites, or exclusions. Sibling tools like plan_volume_arc or design_emotion_blueprint might overlap, but no comparison or situational advice is offered.

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

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 mentions integrating inputs and producing a packaging list, but does not disclose whether the operation mutates state, requires permissions, or how the finalization affects the underlying draft. This is a significant gap for a tool named 'finalize'.

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 states the operation, inputs, and output without redundancy. It is appropriately concise and every phrase contributes to understanding the tool's purpose.

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 are no annotations and no output schema, the description should do more to explain behavioral side effects, expected output structure, and the meaning of '封装清单'. The tool has a low parameter count, but for a finalization operation the missing context leaves the agent under-informed.

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% and the two parameters already have descriptions in the schema. The tool description adds the conceptual role of the inputs (integrating draft and review feedback) but does not add meaning beyond what the schema already provides, so the baseline of 3 applies.

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 a specific action (封装/finalize) and resources (初稿 + 审核改进意见) with an explicit output (终稿封装清单). It is understandable and distinct from sibling tools in intent, though it does not explicitly differentiate itself by naming alternatives.

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?

There is no guidance about when to use this tool versus alternatives like polish_get_advice or review_chapter. The description only implies usage when a draft and review feedback are available, but provides no exclusions, prerequisites, or alternative conditions.

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

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

With no annotations provided, the description carries the transparency burden. It discloses the primary behavior—returning a customization plan and QR code—but does not clarify side effects, such as whether any real contact occurs, whether payment is involved, or what the output exactly contains beyond the plan and QR. It is adequate for an informational tool but not deeply transparent.

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 only two short clauses, front-loaded with the core action ('returns product customization plan + WeChat QR code'), followed by applicable scenarios. Every word earns its place with no redundancy.

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 simple tool with two optional parameters and schema coverage of 100%, the description sufficiently conveys purpose, output, and applicable contexts. It could be marginally more complete by noting default behavior or what the response format looks like, but the current level is adequate.

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 both parameters are already described ('current requirement description' and 'whether to return WeChat QR code'). The tool description adds no extra parameter-level detail, so it meets the baseline but does not go beyond what the schema provides.

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 identifies the tool as an AI customer-service/custom-consultation feature that 'returns a product customization plan + Li Zisheng's WeChat QR code.' It also lists specific applicable scenarios (writer custom version, 1v1 coach, team version, publishing closed loop), which distinguishes it from the content-creation and analytics 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 '适用' (applicable) clause gives clear context for when to use this tool: writer custom version, 1v1 coach, team version, and publishing closed loop. It does not explicitly mention alternatives or when not to use it, but the listed scenarios serve as reasonable usage guidance.

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

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

No annotations are present, and the description does not disclose any side effects, output format, or whether the operation is read-only or mutating, leaving the agent to infer behavior.

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 concise sentence, efficiently conveying the core purpose without unnecessary verbosity.

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 lacks essential details such as output structure, expected behavior, or how the cycle pattern affects the result, making it incomplete for effective use despite the simple parameter.

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?

The only parameter (total_chapters) has no description beyond type and range; its meaning and role in the rhythm generation are unexplained, providing minimal value beyond the schema.

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 tool's function (generates rhythm markers) and specifies the 3-chapter cycle pattern (setup-conflict-release), which distinguishes it from sibling tools like analyze_chapter_rhythm.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., analyze_chapter_rhythm) or any prerequisites or context needed for invocation.

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

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

No annotations are provided, so the description carries full burden. It discloses it performs a read-only analysis (checking), but does not specify what happens for different outcomes, how strict the checks are, or any side effects. Given the complexity of conflict-chain analysis, more behavioral disclosure is needed.

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 one sentence and front-loaded with the main purpose. It is concise, but could be slightly improved by adding usage guidance or behavioral detail without bloating. No waste, but not exceptionally structured.

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's complexity (analyzing conflict chains and foreshadowing), the description is thin. No output schema exists, so it should explain the return format or result interpretation, which it does not. The single-parameter input is simple, but the task is nuanced, and the description does not cover what the tool reports or how to act on 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 coverage is 100%, so the single parameter chapter_text is fully documented in the schema. The description adds context that the chapter text is used for conflict-chain analysis, which reinforces meaning. Baseline 3 is elevated to 4 due to the description's alignment with the parameter's purpose.

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 the tool checks whether a chapter's conflict chain is closed-loop and foreshadowing is retrieved, which is a clear purpose. However, it lacks a specific verb-resource format and does not distinguish itself from sibling tools like ctqa_compliance_check or analyze_chapter_rhythm.

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 usage for CTQA quality checks, but provides no guidance on when to use this tool versus siblings like ctqa_compliance_check or when not to use it. No alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states what content categories are checked, but does not disclose whether results are returned as a pass/fail flag, violation list, score, or whether the operation has any mutation or side effects. This is a significant gap for a tool lacking an output schema.

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 with zero wasteful wording. It is easy to parse quickly, but it is so terse that it omits behavioral and usage guidance that would make the tool robust to invoke.

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 tool is relatively simple, but there is no output schema and no annotations, so the description should compensate by explaining return values, platform-specific behavior, or relation to sibling compliance tools. It does none of this, leaving the description incomplete for confident invocation.

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 only 50%, with chapter_text described as '章节正文' and platform having an enum but no semantic description. The description does not explain that platform selects different compliance rule sets or how the chapter_text input should be structured. It adds minimal meaning beyond the schema.

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 uses a specific verb '检查' (check) and identifies a concrete resource: platform compliance with sensitive words and red-line content categories (political/sexual/violent/plagiarism). It clearly distinguishes this from rhythm compliance tools like check_rhythm_compliance, though it does not explicitly name alternatives.

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 the tool is used for platform compliance checks, but it provides no explicit guidance on when to use this tool versus siblings like ctqa_closed_loop_check or check_rhythm_compliance. There are no exclusions, prerequisites, or context cues beyond the generic purpose.

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

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

No annotations are provided, so the description must convey side effects and behavior. It does not state whether the tool is read-only, whether it modifies existing data, or what output it produces. The term 'design' implies creation, but the description lacks explicit transparency about outcomes or side effects.

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, concise sentence that efficiently conveys the core functionality and key details (emotional arc cycle, per-chapter elements). It avoids unnecessary fluff and is well-structured for quick comprehension.

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 provides sufficient high-level context for a design tool, but it lacks details about expected output, input constraints, or how the blueprint is delivered. Given the absence of an output schema and annotations, the description is not fully complete, though it covers the primary purpose adequately.

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?

The schema parameters (high_concept, target_chapters) have no descriptions, and the tool description does not explain them beyond the general context of planning a book. While parameter names are somewhat self-explanatory, the description adds no specific meaning or constraints, leaving users to guess how they influence the blueprint.

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 tool's function: designing an emotional blueprint for the entire book, including the specific emotional arc cycle (suppression→accumulation→explosion→release) and per-chapter emotion type and intensity. This is specific and distinct from sibling tools like analyze_chapter_rhythm or emotion_probe.

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 does not explain when to use this tool versus alternatives, nor does it mention any prerequisites or scenarios. It only describes what the tool does, leaving the user to infer appropriate use cases.

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

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

With no annotations provided, the description must disclose behavioral traits. It does not mention that the tool likely reads chapter_text and returns a prescription, or whether it modifies anything. The description does not clarify if it is a read-only analysis or if it has side effects, leaving the agent uncertain about the tool's behavior.

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, concise sentence that is front-loaded with the tool's core purpose. It includes the key aspects (final review, emotion prescription, what to add) without extraneous words, maximizing information per word.

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 tool is moderately complex with 2 parameters and no output schema. The description covers the high-level purpose but lacks detail on how the prescription is structured, how the target_emotion influences the output, and any constraints on the input text. Given the absence of annotations and output schema, the description could be more complete to guide the agent on expected behavior.

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?

The schema covers 50% of parameters: 'chapter_text' has a description 'chapter text', and 'target_emotion' has an enum but no description. The tool description mentions 'chapter' and 'emotion', but it does not explicitly clarify that 'target_emotion' selects the desired emotion for the prescription or that 'chapter_text' is the input chapter. It adds some context but does not fully compensate for the schema gaps.

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 tool provides 'emotion prescription for final review' with specific elements (where emotion is missing, what to add, how to add it). It distinguishes from siblings like 'review_chapter' and 'validate_emotion_arc' by focusing on prescriptive adjustments rather than generic review or validation.

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 the tool is for final review of a chapter's emotional tone, but it does not explicitly state when to use it over alternatives like 'emotion_probe' or 'validate_emotion_arc'. No exclusions or prerequisites are mentioned, leaving usage context somewhat implicit.

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

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

No annotations are provided, so the description carries the full burden of transparency. It does not mention side effects, permissions, or that it is a read-only operation. It implies analysis but does not explicitly state non-destructive behavior or any limitations.

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, concise sentence that conveys the essence without unnecessary words. It is well-structured and front-loaded, immediately stating the action and scope.

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 tool is simple with one parameter, and the description explains the purpose and dimensions. However, it does not indicate what the output will look like or how to interpret results. Given no output schema, more context on expected results would improve completeness, but it is adequate for a basic understanding.

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?

The schema includes one parameter 'chapter_text' with a description '章节正文' (chapter text), which is clear and covers the parameter's purpose. The tool description adds context about emotional layers, but the parameter description alone is sufficient to understand the input. Since schema coverage is 100%, baseline is 3; the description provides marginal additional meaning.

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 tool's purpose: to check emotional layers of a chapter across six dimensions. The verb '检查' (check) is specific, and the subject '情绪层次' (emotional layers) is defined. It distinguishes from sibling tools by focusing on emotion analysis, though it does not explicitly contrast with alternatives.

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 provides no guidance on when to use this tool versus other analysis tools (e.g., rhythm analysis, compliance checks). It only states what it does, without context on appropriate scenarios or conditions for use.

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

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

No annotations are provided, so the description must disclose behavior. It indicates the tool returns templates, but does not describe the structure, size, or any operational constraints (e.g., what happens if the emotion parameter is omitted, whether it is a read-only operation, or any data source specifics). This is minimal disclosure for a tool with no annotation support.

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 lists the five emotions and clarifies that these are 'standard arc templates'. It is efficient with no redundant wording, though it could be slightly clearer about the tool's output (e.g., 'returns templates' vs. 'gets templates').

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's simplicity (one enum-d parameter, no output schema), the description covers the basic purpose and available emotions. However, it could benefit from mentioning what kind of template data is returned (e.g., structure, format) or how it relates to other emotion-related tools, which would improve completeness for an agent selecting among many sibling tools.

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?

The single parameter 'emotion' is fully enumerated in the schema with five values, so the schema covers its meaning. The description adds the context of the five emotions but does not elaborate on how the parameter affects the output beyond triggering the corresponding template. With 0% schema description coverage but a simple enum, baseline 3 is appropriate.

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 tool retrieves standard arc templates for five dominant emotions (燃/虐/爽/甜/悬). It identifies the resource (emotion arc templates) and the specific scope (five listed emotions), which is clear but not explicitly differentiated from sibling tools like design_emotion_blueprint or validate_emotion_arc, though the names suggest distinct purposes.

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 used to fetch standard templates for a given emotion, but does not explain when to use it over alternatives like design_emotion_blueprint or emotion_prescription_review, nor does it mention any prerequisites or exclusion criteria. The default value hints at common usage but lacks explicit guidance.

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

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

No annotations are provided, so the description carries the transparency burden. The verb and naming clearly indicate a read-only retrieval, and the description adds useful output content. However, it does not explicitly mention whether the template is static, whether any side effects occur, or what format the response takes.

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 one compact sentence with a parenthetical clarification. Every part contributes either the resource name, the content type, or the intended use, with no filler.

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 zero-parameter, non-mutating retrieval tool, the description gives enough orientation about what will be returned: standard chapter cards and a body-call template. The lack of output schema is somewhat mitigated by that explicit content description, although it does not mention how the template should be consumed.

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?

There are zero parameters, so the baseline is 4. The description contributes meaning by clarifying that the returned template consists of standard chapter cards and a main-text call template, which is useful context even though there is no input schema to explain.

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 verb 获取 (get), the resource (MCP 写作模板), and the deliverable (标准章卡+正文调用模板). This is distinguishable from sibling template tools like get_emotion_arc_templates and get_zhui_xu_rhythm_template because it explicitly focuses on the MCP call-format template.

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?

There is no guidance about when to use this tool versus alternatives, no exclusions, and no comparison to sibling tools. The phrase 供智能体参考调用格式 gives an intended audience/purpose, but not a decision-relevant usage condition.

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

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

With no annotations, the description carries the full burden. It discloses that local and edge versions return different kinds of information (actual progress vs. guidance), which is useful behavioral context. However, it omits details about error handling, response format, and what happens if the job_id is invalid or the job is not found.

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 concise sentence with no filler words. It front-loads the action and clearly communicates the core behavior and version difference, making every word earn its place.

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 tool with one parameter and no output schema, the description is minimally sufficient but leaves gaps. It does not specify the structure of the returned progress/guidance, possible statuses, or error conditions, which an agent might need to interpret results correctly.

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%, with job_id documented as '异步任务 job_id'. The description adds no additional parameter semantics, but the schema already provides sufficient meaning, so the baseline score of 3 is appropriate.

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 tool's purpose: querying the status of asynchronous writing tasks. It uses a specific verb ('查询') and resource ('异步写作任务状态'), and the distinction between local and edge versions helps differentiate it from sibling tools like write_chapters_async and cancel_write_job.

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?

No explicit guidance is provided on when to use this tool versus alternatives such as cancel_write_job or write_chapters_async. The local/edge version distinction implies environment-specific use but lacks a clear recommendation or exclusion criteria.

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

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

With no annotations, the description carries the full burden for behavioral transparency. It adds some context by revealing the template's composition (four features), but it does not explain whether the template is static, how it should be applied, or if there are any side effects. Since it is a simple getter, this level of detail is acceptable but not comprehensive.

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 states the primary purpose and then lists the four features, achieving maximum clarity with zero redundancy. It is concise and well-structured, containing no filler or irrelevant details.

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 tool with no parameters and no output schema, the description provides adequate context by specifying exactly what template is returned and its key components. However, it does not describe the template format or how to interpret it, which might be needed for an agent that has never seen the template before. This slight gap prevents a perfect score.

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?

The tool has zero parameters and the schema coverage is 100% (trivially). Since there are no inputs to document, the description does not need to explain parameters. The baseline score of 4 is appropriate, and the description adds no unnecessary information about inputs, which is suitable for a parameterless getter.

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 tool's purpose: '获取赘婿风格节奏模板' (get the Zui Xu style rhythm template) and enumerates the four specific features it covers (长短句交替, 负奢华, 情绪外化, 对仗金句). This distinguishes it from sibling template tools like get_emotion_arc_templates and get_mcp_template by focusing on a unique style.

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?

No guidance is provided on when to use this tool versus alternatives such as get_emotion_arc_templates or coach_strategy_template. The description only states what the tool does, without any context about when it is appropriate or when it should be avoided, leaving the agent to infer usage solely from the name.

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

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

No annotations are provided, so the description must fully convey behavior. It describes the guide's function but does not explicitly state that it is non-destructive or what output it produces. It also does not mention any side effects or limitations, leaving transparency incomplete.

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 to the point, covering all essential information without redundancy. Each sentence adds value, and the step list is clearly organized.

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 provides a complete overview of the workflow and parameter usage. It lacks explicit mention of output format or error handling, but for a guide tool, the context is generally sufficient. The absence of an output schema is mitigated by the clear purpose.

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?

The description significantly enriches the parameter meanings: 'step=0 总览，1-7 单步' clarifies the integer range, and '自由提问（自动匹配步骤）' explains the purpose of the 'question' parameter. This goes well beyond the basic schema 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 that this tool provides step-by-step guidance for a complete workflow from creating works to importing to kdwrite, and enumerates the specific steps. It distinguishes itself from sibling tools that focus on specific actions like analysis or validation.

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 explains how to use the 'step' parameter (0 for overview, 1-7 for individual steps) and mentions free-form questions with automatic step matching. However, it does not explicitly state when to use this guide versus other tools, though the nature of a guide is implicitly clear.

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

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

No annotations are provided, so the description must carry the burden of disclosing side effects, permissions, or reversibility. It states only that it analyzes and suggests, implying a read-only operation, but does not explicitly confirm non-destructiveness, required permissions, or any potential side effects.

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, concise sentence that conveys the core functionality without redundancy or unnecessary words. It is well-structured and easy to parse.

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 two parameters with no explanations and no output schema, the description is incomplete. It lacks information on how parameters affect the result, what the output format or content is, and any prerequisites or usage context, leaving significant gaps for the agent.

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?

The description completely omits explanation of the two parameters (tone and genre) and their roles in the analysis. With 0% schema coverage and no parameter descriptions, the agent is left uninformed about how to set these fields, despite them having defaults and an enum for genre.

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 tool's function: analyzing humor gene types (self-deprecating/contrast/roast/awkward/pun) and providing density suggestions. It uses a specific verb 'analyze' and a distinct resource, differentiating it from sibling tools like 'analyze_chapter_rhythm' or 'emotion_probe'.

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 does not specify when to use this tool versus alternatives, nor does it provide conditions, exclusions, or selection criteria. There is no guidance on input requirements or contexts where other tools would be more appropriate.

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

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

No annotations are provided, so the description carries full responsibility. It discloses the outputs (skeleton components) but does not mention whether it creates/modifies files, requires permissions, is idempotent, or any side effects. This is risky for an initialization action that likely writes data.

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, concise sentence that front-loads the core purpose and lists key outputs. No wasted words; it is efficient and complements the schema well.

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 no output schema and no annotations, the description should explain behavioral implications. It lists generated components but omits return format, whether it's safe to rerun, if it affects existing data, or any prerequisites. For an initialization tool, this is insufficient context.

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 the description echoes the parameter names without adding detail beyond the schema. It lists 'genre/platform/high-concept' but provides no examples, constraints, or format guidance beyond the schema's existing 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 tool initializes a novel project and generates setting skeleton components (like worldview, protagonist, golden finger, etc.), based on genre/platform/high-concept. It is specific and distinguishes from siblings like chapter analysis or rhythm tools, though it doesn't explicitly name alternatives.

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?

No explicit guidance on when to use or avoid this tool. The iterative nature ('initialize') implies it's for project setup, but there is no mention of prerequisites, ordering relative to other tools, or when it should not be used.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It conveys that the tool writes an export file, runs only locally, and that the edge function fallback behaves differently (returns a guide). It omits details like overwrite behavior or return-values, but the core behavior is transparent enough.

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 short and information-dense: two sentences cover the purpose, zip structure, local-run requirement, and the edge-function limitation. No redundant details.

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's moderate complexity, the description covers the essential behavior, output format, and runtime constraints. It lacks explicit return value details for local execution, but that is partially inferable from the output_path parameter and the zip description.

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?

The schema covers 100% of the 6 parameters, so the description doesn't need to restate them. It adds useful context about the output artifact structure but does not explain each parameter beyond what the schema already provides.

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 tool's action: '把本地章节文件夹导出为口袋写作 .kd 文件', specifying the input (local chapter folder) and output (a .kd zip containing 正文.txt and 作品相关.txt). This differentiates it from sibling tools like kd_import_preview, kd_upload_to_cos, and kd_validate_file.

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 explicitly says the tool requires local execution ('需本地运行（node dist/http.js 或 stdio）') and that an edge function call will only return generation guidance. This gives clear when-to-use context, though it does not explicitly mention alternative tools.

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

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

With no annotations, the description carries the burden. It communicates a read-only 'preview' action, implying no modifications, but does not explicitly state safety, dependencies, or error behavior. It adds some value (what content is previewed) but lacks depth on side effects or auth requirements.

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 immediately states the core action and output. Every word is necessary, and it is highly scannable for an agent.

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 no output schema, the description enumerates the expected preview content (title, author, chapter titles, beginning of text), covering return value expectations. It does not address limits or errors, but for a simple preview tool with minimal parameters, it is reasonably complete.

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 only 50% (kd_path described, preview_chapters not). The tool description adds no parameter information beyond the schema. It does not explain preview_chapters semantics (e.g., how many chapters to preview) even though the schema lacks a description for it. This is a significant gap.

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 tool previews KD file content, listing specific elements (title, author, chapter titles, beginning of text). This distinguishes it from siblings like kd_validate_file (validation) and kd_upload_to_cos (upload), making its purpose 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 usage for inspecting KD files before import, but does not explicitly state when to use it versus alternatives or provide exclusions. Context is clear enough for an agent to infer typical use, but explicit guidance is missing.

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

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

With no annotations, the description carries the transparency burden. It discloses the need for COS credentials and that it returns configuration guidance via an edge function. However, it does not mention potential side effects like overwriting existing objects or error behavior. Adequate but minimal.

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?

Two concise sentences, front-loaded with the core purpose alert. No fluff or redundancy.

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 tool is simple (2 params, no output schema), and the description covers the key action, requirement, and return behavior. However, it doesn't elaborate on failure scenarios, overwrite behavior, or format of the returned guidanceLinda. Given the simplicity, it's adequate but not rich.

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% (both parameters have descriptions), so the baseline is 3. The tool description adds no extra parameter semantics beyond what the schema already provides.

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 action (upload), the resource (.kd file), and the destination (Tencent Cloud COS). It distinguishes this tool from all siblings, none of which involve COS uploads.

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 when to use it (to upload .kd files to COS) but provides no explicit when-not-to-use or alternative tool guidance. Credential requirement is mentioned, which is useful context, but no exclusions or comparisons.

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

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 does reveal what is checked (zip structure, required files, encoding, chapter count) and vaguely mentions an edge function return, but it does not clearly explain the return format, error handling, or whether the operation is purely read-only. No contradiction exists since there are no annotations.

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 concise sentence that front-loads the core purpose and includes specific validation criteria. The second clause about the edge function return is brief and adds some context without unnecessary verbosity.

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 simple one-parameter validation tool, the description covers the main validation targets but leaves the return format ambiguous with '边缘函数返回格式说明' and provides no usage context or prerequisites. It is adequate but not fully complete, as an agent would still be uncertain about the exact output shape.

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?

The tool description adds no information about kd_path beyond what the input schema already provides, and the schema coverage is 100%. Therefore, the baseline score of 3 applies—the parameter is already fully documented in the schema.

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 uses a specific verb (验证/validate) with a concrete resource (.kd file) and lists concrete validation dimensions (zip structure, required internal files, encoding, chapter count). This clearly distinguishes it from sibling validation tools that target outlines, emotion arcs, or rhythm compliance.

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 the tool should be used for validating .kd file format, but it does not explicitly state when to use this tool versus alternatives like kd_import_preview or kd_upload_to_cos. There are no exclusions or named alternative tools, leaving usage guidance only implicit.

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

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

With no annotations, the description carries the full burden. It states the design intent but does not disclose whether the tool is read-only, whether it creates or modifies files, what it returns, or any dependencies on existing project state.

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, front-loaded Chinese sentence states the tool's purpose and the expected structure. No filler words or redundant content.

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 tool has no output schema and no annotations, so the description must provide context. It fails to explain output/return behavior, parameter usage, or integration with the surrounding planning workflow, leaving the agent with only a high-level purpose.

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%. The description does not mention 'volumes' or 'total_chapters', nor their relationship or constraints. Although the parameter names are somewhat self-explanatory, the description adds no semantic value beyond the schema.

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 identifies a specific action ('plan volume arcs') and the exact deliverable ('independent small climax-trough-big climax structure for each volume'). This distinguishes it from sibling rhythm/emotion tools like check_rhythm_compliance or design_emotion_blueprint.

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 is only implied by the purpose: use this when planning volume-level arcs. It provides no explicit when-to-use vs alternatives, no exclusions, and no workflow context, but the naming and scope offer some guidance.

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

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

由于没有任何注释，描述承担全部行为披露责任。工具描述仅说“给出润色方向”，但未说明是否有副作用（如是否修改内容）、是否需要权限、返回格式或是否只读，行为特征不透明。

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?

描述只有一句话，直接点明核心功能，无冗余信息，前置了关键内容，简洁高效。

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?

工具本身简单（单参数、无输出模式），描述提供了核心功能，但未包含使用场景、前置条件或与其他工具的关系，在众多兄弟工具中缺乏足够的上下文信息，完整性有限。

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描述覆盖率为100%，故按基线评分3。

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?

描述明确说明工具给出章节的润色方向，并列举了节奏、描写、对话、金句四个具体维度，动词和资源清晰，与同层级专注于特定方面的工具（如analyze_chapter_rhythm、check_rhythm_compliance）区分明显。

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?

描述未说明何时使用此工具，也未提及任何替代方案或排除情况。用户无法从描述中判断应在哪些场景下选择本工具而非其他润色相关工具，缺乏使用引导。

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

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

No annotations are provided, so the description carries the full burden. It only says to import data, but does not disclose whether existing data is overwritten, how validation is handled, whether rates are normalized, or what errors may occur. The write behavior is implied but not detailed.

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, concise sentence that front-loads the purpose. It is minimal but not verbose, and there is no wasted wording. It could arguably be expanded, but as it stands it is appropriately sized for a simple tool.

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?

Despite the low complexity (3 simple params, no nested objects, no output schema), the tool is a write operation and lacks critical behavioral details such as idempotency, error handling, and whether rates are validated against the min/max constraints. With no annotations, the description is too sparse to be fully actionable.

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?

The description mentions completion and follow rates, which maps to two of the three parameters, but it omits the 'book' parameter entirely. The schema itself only describes 'book' (书名), so the description partially compensates by naming the rates but does not clarify how 'book' is used (likely as an identifier). Given low schema coverage (33%), the description adds some but not sufficient meaning.

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 tool imports real reader data (completion/follow rates) into a local metrics library. The verb 'import' and resource 'local metrics library' are specific, and the mention of the two rates distinguishes it from reporting siblings like reader_metric_report.

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?

No guidance is provided on when to use this tool versus other import tools (e.g., kd_import_preview) or under what conditions it is appropriate. There is no explicit or implied context about prerequisites or alternatives.

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

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

没有提供注解，描述承担全部责任，但描述仅说明

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?

描述只有一句话，简短且直接，没有冗余内容，每个词都有意义，结构上前置了核心动作。

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?

工具简单但描述不完整：没有输出schema，也没有说明返回内容或报告形式，且缺少使用条件。考虑到没有注释，描述应更全面地解释行为，但实际仅覆盖了输入指标，缺乏对输出和适用场景的说明。

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描述覆盖率为67%，其中completion_rate和follow_rate已有描述（0-1），且描述中也提到了这两个指标。但描述没有为comments参数提供额外语义，也没有为任何参数添加新的含义，因此基线为3。

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?

描述明确说明

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?

述没有任何关于何时使用或何时不使用的指导，也未提及替代工具。虽然兄弟工具可能提供类似功能，但没有明确说明，因此缺乏使用指南。

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

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

The description discloses that the tool scores on six dimensions and provides improvement suggestions, and mentions the agent may rewrite based on scores. However, it does not specify the scoring scale, output format, or whether the tool itself executes the rewrite. With no annotations, the description only partially carries the transparency burden.

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 with a parenthetical list of the six dimensions. It is concise, free of redundancy, and directly conveys the core purpose.

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?

Without an output schema or annotations, the description should specify the result format and any side effects. It mentions scoring and suggestions but not the structure, and the '重写' (rewrite) action is ambiguous. The description is adequate for a basic understanding but lacks detail on platform-specific behavior and output.

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?

The description does not explain any parameters. The `platform` field is left undocumented in both schema and description, and the description does not clarify how `chapter_text` or `chapter_title` are used. The six dimensions are output criteria, not parameter semantics.

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 identifies the tool as a single-chapter editorial review using six specific dimensions (rhythm, emotion, dialogue, hook, consistency, compliance). It distinguishes from sibling tools that focus on individual aspects by offering a comprehensive '主编级' (editor-in-chief-level) review, and the verb '审核' makes the action explicit.

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?

There is no explicit guidance on when to use this tool versus alternatives such as analyze_chapter_rhythm or check_rhythm_compliance. The description implies comprehensiveness but does not state when to prefer it or any prerequisites.

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

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

The description indicates the output is a skeleton with placeholders, which is useful. However, no annotations are provided, and the tool likely mutates project state (creates a roadmap), but the description does not mention any side effects, persistence, or permission requirements. Since it's a generation tool, it may be read-only, but that is not stated.

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 concise sentence that conveys the core function and output structure. It is front-loaded with the purpose. Minor loss for not elaborating on parameters, but it avoids 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 the tool's moderate complexity (4 parameters, 2 enums, no output schema), the description provides an overview of the output but lacks detail on how genre and platform influence the roadmap. With no annotations, more behavioral context would be needed for full completeness.

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?

The schema already describes high_concept and target_chapters, but genre and platform are only enums without description. The description does not add meaning to these parameters. Since schema coverage is 50%, the description could have clarified the role of genre and platform, but it doesn't. Baseline 3 is appropriate.

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 tool creates a chapter roadmap by splitting a high concept into volumes and chapter skeletons, with each chapter having core conflict and hooks. It is distinct from siblings like plan_volume_arc and batch_generate_chapter_cards, though it doesn't explicitly name them.

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 use when starting a novel from a high concept and target chapter count, but does not provide explicit when-not-to-use or alternatives. It is clear enough contextually among siblings but lacks explicit guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'inject into writing context', implying a state-changing action, but does not explain the scope (does it affect the current session? persist?), reversibility, idempotency, or any side effects. For a tool that mutates writing context, this is insufficient behavioral transparency.

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, concise sentence that front-loads the tool name and uses a colon to explain its function. It avoids fluff and gets to the point. However, the dense metaphor might sacrifice clarity for brevity, and adding a brief note about parameters would have been possible without bloat.

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 only two simple parameters and an output-free signature, the tool is relatively simple, but the description fails to explain the practical implications of calling it. It doesn't mention what the agent should expect after invocation (e.g., a confirmation, a success message, or how the injected genes affect subsequent operations). The description is insufficient for an agent to understand the tool's role in a multi-step writing workflow.

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%, and the description provides no parameter-level details. Neither 'genre' (despite having a rich enum of genres) nor 'theme' is mentioned in the description. The description's phrase '爽点模式' could indirectly relate to 'theme', but it's not explicit. The schema itself is self-documenting (enum, defaults), but the description adds no value for parameter understanding.

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 uses a specific verb-resource combination ('同步创世基因' sync genesis gene) and clearly explains its function as injecting viral-hit distilled genes (internet-sense anchor lexicon + gratification patterns) into the writing context. This distinguishes it from sibling tools like 'humor_gene_sequencing' (which sequences genes) or 'analyze_chapter_rhythm' (which analyzes rhythm). However, the heavy use of metaphor ('创世基因', '注入') might be slightly ambiguous without cultural context, preventing a perfect score.

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?

There is no guidance on when to use this tool versus its many siblings, no mention of prerequisites, side conditions, or when NOT to use it. The description simply states what it does without contextualizing its placement in a workflow. Since siblings like 'batch_generate_chapter_cards' or 'write_chapters_async' could plausibly be alternatives, the lack of guidance is a clear gap.

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

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

No annotations are provided, so the description must carry full behavioral disclosure. It reveals the validation criterion but does not disclose whether the tool is read-only, what it returns (pass/fail vs. detailed report), whether it modifies state, or how 'healthy' is operationalized. This is insufficient for a validation tool with no annotation support.

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 with a precise main clause and a clarifying parenthetical. Every word adds relevant detail, with no redundancy or filler.

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 no output schema, no annotations, and a single nested-object parameter, the description needs to compensate by explaining expected input shape and result format. It only states the validation criterion in general terms, so an agent cannot confidently predict the tool's output or interpret the result for downstream steps.

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 high (100%) for the single 'blueprint' parameter, so the baseline is 3. The description adds a slight semantic link between the blueprint and chapter emotional arrangement but still does not explain what fields or structure the blueprint object must contain, and the schema itself provides no additional constraints beyond the parameter name.

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 tool validates an emotion arc by checking chapter emotional arrangement against the '压抑→释放' (suppression→release) rhythm and healthy intensity distribution. This is a specific verb+resource+scope formulation that distinguishes it from broader tools like analyze_chapter_rhythm or plan_volume_arc.

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 gives no explicit guidance about when to use this tool versus alternatives such as check_rhythm_compliance, design_emotion_blueprint, or analyze_chapter_rhythm. It does not state prerequisites, sequencing, or exclusions, so the agent must infer usage context from the name alone.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the check occurs but doesn't explain what happens on failure, whether it stops at first error, or what the output format is. This is a significant gap for a validation tool.

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 concise sentence with no fluff. It efficiently communicates the tool's core function.

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 one-parameter tool with no output schema, the description is somewhat adequate but omits critical details about return values or result handling. An agent would need to infer what 'format requirements' means and what a successful validation returns.

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% ('章卡数组' explains the cards parameter). The description adds minimal insight beyond restating the batch aspect, so it meets the baseline but doesn't enrich the parameter meaning.

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 action ('validate') and resource ('chapter cards') in batch, distinguishing it from the singular validate_outline_card tool. However, it doesn't explicitly name the alternative, so it doesn't fully differentiate from siblings, but the 'batch' keyword implies the intended use case.

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 batch context implies usage when multiple chapter cards need validation, but there is no explicit guidance on when to choose this over the singular tool or other compliance tools. No exclusions or alternative mentions are provided.

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

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

无注解，描述承担全部行为负担。描述仅说明检查必填字段和字数契约，但未披露是否只读、是否修改数据、返回结果的形式或错误处理方式，行为不透明。

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?

描述仅一句话，但信息密度高，列出了关键检查项和契约，无冗余内容，结构紧凑且前端清晰。

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?

工具涉及嵌套对象且无输出模式，描述列出了检查项但未说明验证规则的具体实现（如字数契约的具体数值）或返回结果的结构，对于验证类工具信息尚不充分，但已有基础框架。

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?

参数card的schema描述已说明为“章卡对象（含chapter_card字段）”，覆盖率为100%。描述未在此基础上添加更多参数细节，未提供额外的含义，故维持基线3分。

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?

描述明确指定了动作“验证”和对象“章卡格式”，并列出了具体检查的必填字段（核心冲突/节奏位置/爽感预算/章末钩子）和字数契约，清晰地区分了与其他验证工具（如validate_outline_batch）的用途。

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?

描述隐含了用于验证单个章卡的场景，但未明确说明何时使用此工具而非其他校验工具（如validate_outline_batch），也没有提及替代方案或前置条件，仅通过名称和兄弟工具列表间接暗示。

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

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

With no annotations provided, the description carries the full burden. It discloses the async nature (returns job_id), that text is generated by the agent's own model ('正文由智能体用自己的模型生成'), and that the local version writes to disk ('本地版会落盘到 book_dir'). This goes beyond a generic 'write' statement, though it omits details like error handling or overwrite behavior.

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 two sentences, each carrying essential information: the first states the core function and returns, the second explains the generation mechanism and side effect. There is no redundancy or filler, and the purpose is 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?

Given there is no output schema or annotations, the description covers the key elements: input, output (job_id and writing guidance), async behavior, and local disk write. It does not explain what '写作指引' means or how to track the job, but the existence of sibling tools like get_write_status and cancel_write_job partially fills this gap. Overall, it is sufficiently 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 100%, with book_dir described as '正文输出目录' and chapters as '章卡数组（含 chapter_index/chapter_card/title）'. The tool description adds minimal extra meaning, mainly repeating that a chapter card list is accepted and that book_dir is the output directory. It adds nothing about the semantics of the fields within chapter cards, so it meets the baseline but does not elevate.

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 tool's purpose: '异步批量写正文' (asynchronously batch write main text), names the input ('接受章卡列表'), and output ('返回 job_id 与写作指引'). It distinguishes itself from sibling tools like 'batch_generate_chapter_cards' by focusing on writing text rather than generating cards, and the async nature is explicit.

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 provides clear context for use: it accepts a list of chapter cards to produce the main text. This implies it should be used after chapter cards are available, and the return of a job_id suggests a subsequent status check with get_write_status. However, it does not explicitly mention alternatives or exclusions, so it falls short of the highest bar.

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