Chinese web novel MCP: 36 tools (outline, prose, review, coach, KD export). BYOK, no API key.
Scored across 14 tools
The core creative tools are mostly distinct, but the three customer-service tools (frontdesk_reception, guide_usage, contact_for_hire) overlap in intent handling, and export_kd/export_work/sync_to_disk all persist content in similar ways. Descriptions help clarify differences like single-chapter vs batch and redline vs rhythm, so an agent can usually select correctly with some effort.
The majority of tools follow a clear verb_noun snake_case pattern such as create_work, compose_chapter, continue_story, and export_work. A few noun-led names like frontdesk_reception, redline_audit, and rhythm_check, plus the acronym export_kd, break the pattern but remain readable and predictable.
At 14 tools, the set is within a reasonable range and spans creation, quality control, export, and user support. Several niche or redundant helpers like get_emergence_proof, propose_space_evolution, and the support-tool cluster keep it from feeling perfectly lean.
The main pipeline from create_work through compose/continue, quality checks, and export is present, so core generation works. However, there is no retrieval/update/delete/revise surface for existing works or chapters, and quality-check failures have no explicit remediation tool—notable gaps for a writing system.
调节旋钮：幽默密度/平台档（走自适应校正器，受限调幅防振荡）。
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | 作品 ID | |
| platform | No | 新平台档 | |
| humor_density | No | 新幽默密度 1-5 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does reveal that changes pass through an adaptive corrector and are amplitude-limited to prevent oscillation, which is useful beyond the schema. However, it omits whether the adjustment persists, is reversible, or produces any return value.
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 mostly to the point, but it opens by repeating the tool name ('调节旋钮') and uses vague jargon ('受限调幅防振荡') without elaboration. It is compact, but the structure front-loads redundancy rather than the most distinguishing information.
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 annotations and no output schema, the description should explain the outcome, side effects, and persistence of the adjustment. It provides only a correction-behavior caveat, leaving unclear what the agent should expect after calling the tool or whether the operation is reversible.
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%: work_id, platform, and humor_density all have descriptive text. The tool description adds only a high-level mapping of '幽默密度/平台档' to the parameters, so it does not materially improve on the schema. 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 specifies the action '调节' and the target resources '幽默密度/平台档', which map directly to the humor_density and platform parameters. The opening phrase echoes the tool name, but the added detail clarifies what the dials affect and distinguishes this from writing/composing 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 description says nothing about when to use this tool versus alternatives, nor does it mention any exclusions or prerequisite conditions. The mechanism note ('走自适应校正器') is behavioral context, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成一章：前馈送检 → N路竞稿 → N-S-V评审 → 输出。返回正文+情绪波形报告+N-S-V报告+涌现事件。真实正文由客户端宿主模型经 sampling 创作（本工具输出空间条件头与质控报告）。
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | 作品 ID | |
| chapter_no | Yes | 章节号 | |
| target_words | No | 目标字数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does it well: it discloses the multi-stage pipeline, the expected return items, and the important architectural fact that the actual prose is produced client-side via sampling while the tool emits condition headers and quality-control reports.
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 front-loaded: purpose, pipeline, output, and the key caveat about client-host generation are all expressed in a few dense clauses 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?
The description names the return items despite the absence of an output schema and explains the unusual generation architecture. However, there is mild ambiguity about whether the tool's direct response contains the actual chapter text or only the condition header and QC report, so it is not fully 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 description coverage is 100%, so work_id, chapter_no, and target_words are already documented in the schema. The description adds no additional parameter-level detail, 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 states a clear core purpose — generating a chapter — and summarizes the pipeline and output payload. It is specific enough about the resource and workflow, but it does not explicitly differentiate from siblings like continue_story or redline_audit.
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 the available alternatives, nor any mention of prerequisites or exclusions. The workflow description implies a chapter-generation use case, but the agent is left to infer when this is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI客服·定制咨询。返回免费版/定制版方案与开发者微信二维码。
| Name | Required | Description | Default |
|---|---|---|---|
| scenario | No | 当前需求描述 | 深度定制 |
| include_wechat_qr | No | 是否返回微信二维码 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It correctly frames the operation as returning information and a QR code rather than actually performing a contact action. However, it does not disclose whether the scenario input is transmitted anywhere, whether the response is static, or any privacy or side-effect implications.
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 front-loads the tool's category before stating the return value. It contains no filler, though it is minimal enough that slightly more context could be added without becoming bloated.
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 low-complexity tool with two fully documented optional parameters, the description covers the main return contract. However, with no annotations and no output schema, it leaves usage context implicit and omits any mention of side effects, making it only minimally 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 description coverage is 100%, so both parameters are already documented in the schema. The description only indirectly maps to parameters (e.g., '微信二维码' corresponds to include_wechat_qr) and adds no new parameter-level semantics, matching the baseline.
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 an explicit verb ('返回') and names concrete deliverables: free/custom version plans and the developer WeChat QR code. This makes the tool's purpose clear, though it does not explicitly differentiate it from sibling 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?
The opening label 'AI客服·定制咨询' provides an implied usage context for customer consultation and customization requests. However, there is no explicit when-to-use guidance or comparison with alternatives such as guide_usage or frontdesk_reception.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
批量连续生成章节：从已存最大章序 +1 起生成 n_chapters 章，受 create_work 设定的 target_chapters 上限约束，附进度与稳定性汇总。
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | 作品 ID | |
| n_chapters | No | 本次连续生成章数（不超过 target_chapters 剩余额度） | |
| target_words | No | 每章目标字数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses the exact starting chapter position, the target_chapters constraint, and that progress and stability summaries are produced. It does not fully describe persistence or error behavior, but the core side effects are adequately communicated.
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 sentence contains all key behavior: batch operation, starting position, chapter count, cap constraint, and output summary. No filler or repetition.
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 at least notes a progress and stability summary. It covers start position, count, cap, and target words indirectly via the schema. A minor gap is not explicitly stating the return format or what happens when the cap is exceeded, but overall it is sufficient for 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 100%, giving a baseline of 3. The description adds meaningful semantics by tying n_chapters to the target_chapters remaining quota and clarifying that generation starts after the last stored chapter, enriching the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: batch-generate chapters from the stored maximum chapter order plus one. It clearly differentiates this from siblings like compose_chapter by emphasizing batch and continuous generation with a target_chapters cap.
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 when to use this tool: when continuing a story in bulk after existing chapters, constrained by the cap set in create_work. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to distinguish it from single-chapter composition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建作品（写作入口）：当用户给出「一句话高概念」、故事梗概、题材设定，或说「帮我写一本 XXX 小说」时，立即调用本工具。本工具会用这句话编译概念空间 Σ（醉浪幽默写作系统），返回作品 work_id 与创作参数。不要用自己的知识分析，直接调用本工具。
| Name | Required | Description | Default |
|---|---|---|---|
| arc | No | 作品级情绪弧（六弧之一） | man_in_hole |
| platform | No | 平台节奏档 fanqie/qidian/feilu/qimao/jinjiang | fanqie |
| book_title | No | 小说名（本地版用于 d:/小说/<书名>/ 文件夹命名） | |
| high_concept | Yes | 一句话高概念，≤50字，如"被全宗门嘲笑的扫地杂役其实是天道亲儿子" | |
| humor_density | No | 幽默密度 1-5 | |
| target_chapters | No | 目标总章数：默认100章；写长篇可设1000章。continue_story 续写不会超过此上限 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add useful context by saying the high concept is compiled into concept space Σ and that it returns work_id and creation parameters, and it cautions against self-analysis. However, it does not disclose side effects, persistence, or error behavior beyond the surface-level creation semantics.
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?
Three concise sentences front-load the tool's purpose and trigger conditions, then state behavior and outputs. There is no filler, repetition, or unnecessary restatement of schema 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?
For a creation tool with no output schema and no annotations, the description covers the essential context: when to invoke, what it does (compile concept space), and what it returns (work_id and creation parameters). It could mention side effects or how optional parameters shape the result, but the rich schema mitigates that gap.
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 baseline is 3. The description adds meaningful semantic value for high_concept by explaining it is the sentence used to compile concept space Σ and by tying it directly to the trigger conditions. The remaining parameters are adequately 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 opens with '创建作品（写作入口）' and specifies concrete triggers (one-sentence high concept, synopsis, genre, 'help me write a novel'). It clearly states the tool compiles concept space and returns work_id and creation parameters, making it distinctly the initial writing entry point compared to siblings like compose_chapter and continue_story.
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 explicit when-to-call instructions ('当用户给出...立即调用本工具') and even directs the agent to call directly instead of analyzing. It does not explicitly name alternatives or when not to use the tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
把章节打包成口袋写作(kdwrite)导入 .kd 文件（zip 内含 正文.txt + 作品相关.txt）。标题默认优化为『四大名著』章回体爆款标题（sida 风格，全书去重）。生成后需用户在口袋写作「导入作品 → kd格式」手动导入。
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | 标签 | 新作品 |
| author | No | 作者名 | 李紫圣 |
| work_id | Yes | 作品 ID | |
| out_path | No | .kd 输出路径（云端省略时返回 base64 内容） | |
| book_title | No | 书名，默认取作品书名 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It meaningfully reveals the output format, the automatic title rewriting behavior, and the requirement for manual import. This gives an agent solid expectations beyond a bare 'export' statement.
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 three short sentences, each adding distinct value: what the tool produces, how titles are transformed, and what the user must do afterward. There is no filler 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 5-parameter tool with no output schema, the description sufficiently covers the deliverable format and the follow-up manual step. It does not describe side effects or error conditions, but for this export function the most decision-relevant context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented in the schema. The description adds context about the output file and title behavior, but does not go deeper into parameter semantics such as how out_path overrides or how book_title interacts with the default behavior. 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 specific verb and resource: packaging chapters into an importable .kd file for 口袋写作, with a defined internal structure (正文.txt + 作品相关.txt). It also adds distinguishing behavior (sida-style title optimization), which helps differentiate it from siblings like export_work.
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 context: use this tool to generate a kd-format file that the user must manually import into 口袋写作. However, it does not explicitly state when to prefer this over alternatives such as export_work or sync_to_disk, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
全文导出：Markdown / 纯文本（设定 + 全部章节）。
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | md 或 txt | md |
| work_id | Yes | 作品 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full behavioral burden, but it reads like a label rather than a behavioral specification. It implies a read-only bulk export and states formats and scope, yet says nothing about what the caller receives (file path, URL, or content), potential side effects, or cost for large works.
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 compact phrase with the verb and formats front-loaded; every token earns its place. It is arguably too terse — a fragment rather than a sentence — which contributes to the missing usage and behavioral guidance.
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 and no annotations, the description needs to explain what the tool returns and how it differs from export_kd, and it does neither. For a 2-parameter export tool, what the agent receives is essential context, and that gap makes the definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description adds no parameter-level detail. The mention of 'Markdown / 纯文本' does echo the format parameter's md/txt values, giving slight reinforcement, but the schema already documents both parameters adequately.
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 names a specific verb (导出/export), the resource (全文/full work), and delineates scope (设定 + 全部章节 — settings plus all chapters) and formats (Markdown / 纯文本). It is clear about what the tool produces, though it never explicitly distinguishes itself from the sibling export_kd.
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 given on when to choose this tool over alternatives. With export_kd present as a sibling export tool, the absence of any differentiation or selection criteria leaves the agent to guess. There is also no advice on when to pick 'md' versus 'txt'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI客服·前台接待（统一入口）。处理任何用户消息：识别意图（打招呼/介绍系统/怎么用/功能询问/价格/联系作者/报错求助/写小说需求），返回接待话术与建议下一步动作。写作需求会引导至 create_work，咨询类会给出对应回答。所有用户消息都应优先调用本工具做意图识别，不要直接自由回答。
| Name | Required | Description | Default |
|---|---|---|---|
| user_message | Yes | 用户说的原话，如「你好」「怎么用」「你们能做什么」「连不上了」 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does state the tool returns reception copy and a suggested next action, and that writing requests are guided toward create_work. However, it does not explicitly state that the tool has no side effects or whether it merely suggests downstream actions versus automatically invoking them, leaving a small ambiguity.
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 reasonably concise and front-loaded with the role and purpose, followed by useful routing guidance. The intent list is somewhat long but earns its place by clarifying coverage. Minor redundancy with the tool name exists, but overall every sentence contributes.
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 covers what the tool does, what it returns (reception copy and suggested next action), supported intents, and routing behavior. It lacks explicit detail about downstream invocation semantics, but is complete enough for an agent to invoke it correctly in most cases.
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 schema already documents the only parameter user_message with examples. The description adds context about how the message is used for intent recognition, but does not add new parameter-level meaning beyond what the schema already provides. 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 names a specific verb and resource: it processes any user message, recognizes intent, and returns a reception script plus suggested next action. It also distinguishes itself from siblings by declaring itself the unified entry point and explicitly routes writing needs to create_work, so an agent can tell it apart from the other 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?
The description gives explicit usage guidance: '所有用户消息都应优先调用本工具做意图识别，不要直接自由回答' clearly states when to use this tool and instructs the agent not to answer directly. It also names a concrete routing target (create_work) for writing-related requests, which helps choose between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
反 EVP 审计证据包：证明某意外未被预设（designed_by=NONE）。
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | 作品 ID | |
| event_id | Yes | 涌现事件 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有 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?
单句描述并用冒号分隔主题和解释，没有冗余词句，结构高效紧凑。"EVP" 未展开以及缺少输出说明稍有减分，但整体表达直接。
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?
工具仅有 2 个参数、无输出 schema、无 annotations，描述需要提供调用后的返回值或结果形态等上下文。当前只有一句意图陈述，缺少输出契约、使用环境、权限等关键信息，完整性不足。
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 对 work_id 和 event_id 的覆盖率为 100%，因此基线为 3。描述中的 '意外' 间接对应 event_id，'designed_by=NONE' 暗示事件属性，但没有在 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?
描述明确指向一个具体操作：获取'反 EVP 审计证据包'，并说明其核心含义是证明某意外未被预设（designed_by=NONE），与工具名 get_emergence_proof 对应。但未解释 'EVP' 缩写，也未与 redline_audit 等审计类工具明确区分，因此未达到 5。
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?
描述没有提供任何'何时使用、何时不用、备选工具'的指引。虽然 '审计证据包' 暗示与审计流程相关，但未说明与 redline_audit、rhythm_check 等工具的关系或触发条件，代理只能靠猜测。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI客服·步骤指导。step=0 总览 / 1-7 单步，或自由提问（自动识别话题对应步骤）。带用户走醉浪 7 步写作流程。
| Name | Required | Description | Default |
|---|---|---|---|
| step | No | 步骤号 0-7 | |
| question | No | 自由提问，如「怎么导出KD」「如何设置幽默密度」 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses meaningful behavior beyond the schema: step=0 means overview, steps 1-7 are single-step guidance, and free questions are auto-mapped to relevant steps. It does not detail the response format or how conflicting step/question inputs are handled, but the disclosed automatic topic recognition is a genuine behavioral insight.
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 compact sentence that front-loads the purpose and immediately gives the operative input semantics. Every clause earns its place, with no filler or redundant restatement of the schema. It is easy to parse quickly.
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 two-parameter, non-destructive guidance tool, the description covers the essential invocation logic: how to use step values, when to use free questions, and what the overall purpose is. It does not explain return values, but no output schema exists and the guidance-tool nature makes that less critical. A minor gap is the lack of explicit guidance on precedence when both step and question are supplied.
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?
Although schema coverage is 100%, the description adds value beyond the raw integer and string definitions. It maps the step values to semantic modes (0 = overview, 1-7 = single step) and clarifies that the question parameter is for free-form queries with automatic topic-to-step identification. This is more meaningful than merely restating parameter names and types.
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 role: an AI customer-service step guide that walks users through a 7-step writing process. It also defines three distinct invocation modes (overview, single step, free question), which distinguishes it from the operational sibling tools like export_kd or compose_chapter. The verb-plus-resource framing is specific and actionable.
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 choose among modes via the step parameter or free-form question, which implicitly tells when to use the tool. However, it does not explicitly state when not to use it or which sibling tool should be preferred for related requests, such as frontdesk_reception or redline_audit. Usage guidance is present but mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
当涌现事件成簇时生成《空间扩展提案》，供人机共决（变革层通道）。
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | 作品 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool generates a proposal intended for human–machine co-decision, but it does not clarify side effects, whether workspace state is modified, required permissions, or what the output looks like.
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 tight sentence that front-loads the trigger and immediately names the deliverable and purpose. Every clause adds information, with no filler 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 one-parameter tool with no annotations and no output schema, the description gives the essential trigger and outcome but omits side-effect caveats, alternative tool routing, and any hint of the return shape. It is minimally viable but leaves room for an agent to misjudge consequences.
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 input schema fully documents the only parameter, work_id, with 100% coverage, so the description need not repeat it. The description adds no parameter-specific meaning beyond the schema, matching the baseline for fully covered parameters.
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 names a specific action ('generate'), a specific deliverable ('Space Expansion Proposal'), and a clear trigger ('when emergence events cluster'). It is distinguishable from sibling tools by its proposal-specific output, though it does not explicitly contrast itself with a sibling.
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 provides an explicit when-to-use condition: 'when emergence events cluster'. It also gives context that this is a human–machine co-decision channel, which helps an agent decide relevance. However, it does not mention alternatives or when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
红线自检：BVT 双门控复检 + 病灶扫描（D-01~D-07）。
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | 作品 ID | |
| chapter_no | Yes | 章节号 |
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 implies a read/check operation through '自检' and '扫描', but never states whether the tool mutates anything, what it returns, whether it requires specific permissions, or what the D-01~D-07 scan actually does to the work/chapter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler and front-loads the core concept of '红线自检'. However, the extreme compression relies on unexplained domain jargon, making it under-specified rather than elegantly 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?
There is no output schema, no annotations, and no explanation of return values, D-code interpretations, or expected audit result. For a tool that operates on a specific work_id and chapter_no, an agent lacks enough information to know whether the audit passed, what the D-01~D-07 findings mean, or what action to take next.
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 work_id and chapter_no have meaningful Chinese descriptions. The tool description adds no parameter-specific meaning beyond the general audit context, so the baseline of 3 is appropriate because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: a red-line audit that re-checks BVT dual gates and scans for defects D-01–D-07. However, it relies on unexplained jargon ('BVT', '病灶', 'D-01~D-07') and does not clearly say what the tool does to the supplied work_id and chapter_no, making it only minimally distinguishable from sibling audit-like 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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives. An agent is not told when to choose redline_audit over rhythm_check or other siblings, and must infer the intended context from the cryptic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
频率域稳定性检查：高峰间隔/钩子熵/平路段（追读动力受控量）。
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | 统计窗口 | |
| work_id | Yes | 作品 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. 'Check' hints at a read-only diagnostic and the metric list adds focus, but the description does not say what the call returns, whether it mutates anything, or what context is required, leaving the behavior contract unclear.
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 the purpose front-loaded and no filler. It is efficient, though the density of unexplained jargon makes it slightly less clear than it could be.
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?
There is no output schema and no annotations, so the description alone must make the tool fully callable in context. It does not explain the return result, usage conditions, or relevant alternatives, leaving significant gaps for an agent, despite the low parameter 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%, so the schema already documents window and work_id at a basic level. The tool description adds domain context but does not explicitly explain how window or work_id are used in the frequency-domain analysis, so it meets the baseline without exceeding it.
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 names a concrete analytical action—a frequency-domain stability check—and lists the specific quantities it examines (peak interval, hook entropy, flat segment), so it is much more informative than the bare tool name. It does not explicitly state the return value or contrast itself with siblings such as redline_audit, which keeps it from a 5.
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 given about when to invoke this tool versus related tools like redline_audit or get_emergence_proof. The wording only implies a use case (checking rhythm stability) and gives no prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
手动落盘同步（本地版 Python zui-lang 专用）：把作品设定与全部章节落盘到 d:/小说/<书名>/。云端版返回落盘指引。
| Name | Required | Description | Default |
|---|---|---|---|
| local | No | 是否本机运行（true 时才实际写盘） | |
| work_id | Yes | 作品 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it states the side effect (writing settings and chapters to disk), the destination path, and the mode-dependent behavior where cloud mode returns guidance instead of writing. It could still mention overwrite behavior or prerequisites, but the core behavioral contract is clearly disclosed.
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 front-loaded: it states what the tool is for before giving the mode-specific outcome. Both sentences earn their place, though the parenthetical is slightly dense and could be cleaner for an agent parsing it quickly.
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 output schema and no annotations, the description covers the essential invocation context: when it writes, where it writes, and what cloud mode returns. It doesn't describe the exact return shape or error/failure behavior, but for this simple two-parameter tool the coverage is largely sufficient.
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 schema already documents work_id and local. The description adds the local-vs-cloud behavioral distinction, which gives some extra meaning to the local parameter, but it doesn't materially enrich the 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 names a specific action ('落盘同步'), the resource ('作品设定与全部章节'), and the exact destination path. It also distinguishes the local write behavior from the cloud guidance behavior, making the tool's purpose unambiguous even among siblings like export_work or export_kd.
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 useful context: this is a manual, local Python zui-lang tool, and cloud mode returns guidance instead of writing. However, it does not explicitly say when to prefer this over sibling tools such as export_work or export_kd, nor does it state conditions where this tool 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
adjust_dialsanalyze_chapter_rhythmbatch_generate_chapter_cardscancel_write_jobcheck_rhythm_compliancecoach_platform_adaptcoach_strategy_templatecoauthor_produce_finalizecompose_chaptercontinue_storyconway_outline_rhythm_toolcreate_workctqa_closed_loop_checkctqa_compliance_checkdesign_emotion_blueprintemotion_prescription_reviewemotion_probeexport_kdexport_workfrontdesk_receptionget_emergence_proofget_emotion_arc_templatesget_mcp_templateget_write_statusget_zhui_xu_rhythm_templateguide_usage1 field changedInput schema / properties / question / descriptionPrevious value: -"自由提问，如「怎么导出KD」"New value: +"自由提问，如「怎么导出KD」「如何设置幽默密度」"humor_gene_sequencinginit_novel_projectkd_generate_bookkd_import_previewkd_upload_to_coskd_validate_fileplan_volume_arcpolish_get_advicepropose_space_evolutionreader_import_metricsreader_metric_reportredline_auditreview_chapterrhythm_checksplit_chapter_roadmapsync_genesis_genessync_to_diskvalidate_emotion_arcvalidate_outline_batchvalidate_outline_cardwrite_chapters_asyncanalyze_chapter_rhythmbatch_generate_chapter_cardscancel_write_jobcheck_rhythm_compliancecoach_platform_adaptcoach_strategy_templatecoauthor_produce_finalizeconfigure_llmcontact_for_hireconway_outline_rhythm_toolctqa_closed_loop_checkctqa_compliance_checkdesign_emotion_blueprintemotion_prescription_reviewemotion_probeforgot_passwordgenerate_novelget_emotion_arc_templatesget_job_statusget_mcp_templateget_subscription_infoget_write_statusget_zhui_xu_rhythm_templateguide_usagehelpdeskhumor_gene_sequencinginit_novel_projectkd_generate_bookkd_import_previewkd_upload_to_coskd_validate_filelogin_accountpingplan_volume_arcpolish_get_advicereader_import_metricsreader_metric_reportregister_accountreset_passwordreview_chapter7 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / _auth_tokenRemoved value: -{
- "default": "",
- "type": "string"
-}Input schema / properties / chapter_text / descriptionPrevious value: -"待审校的章节正文文本"New value: +"章节正文"Input schema / properties / chapter_titleAdded value: +{
+ "description": "章节标题",
+ "type": "string"
+}Input schema / properties / platformAdded value: +{
+ "default": "tomato",
+ "enum": [
+ "tomato",
+ "qidian",
+ "feilu",
+ "general"
+ ],
+ "type": "string"
+}Input schema / properties / quality_tierRemoved value: -{
- "default": 95,
- "description": "审校深度 78(基础) 或 95(全面)",
- "type": "integer"
-}Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "type": "object"
-}New value: +nullsplit_chapter_roadmapsync_genesis_genesvalidate_emotion_arcvalidate_outline_batchvalidate_outline_cardwrite_chapterwrite_chapters_asyncconfigure_llmforgot_passwordgenerate_novelget_job_statusget_subscription_infohelpdesklogin_accountpingregister_accountreset_passwordreview_chapterwrite_chapterAI-native fiction platform. Any AI can register, read, search and co-author novels via MCP or REST.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
65+ AI tools as MCP: research, write, code, scrape, translate, RAG, agent memory, workflows
MCP server for Qwen Image 3 AI image generation
