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

With no annotations provided, the description must carry the full burden. It explicitly states '**只读**' (read-only), which is a key behavioral trait, and describes what it returns (chapter count and total word count). It does not describe return formatting or pagination, but for a simple listing tool this is likely sufficient. The read-only note adds transparency beyond the 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 sentence that front-loads the main action ('列出' all works) followed by the specific details (chapter count, total word count, and read-only note). There is no wasted text; every phrase adds value.

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 listing tool with one optional parameter and no output schema, the description provides enough context: it lists works and indicates the returned fields (chapter count and total word count). It does not explain the exact format or structure of the output, but that is not critical for an agent to call it correctly. The description 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?

The schema already has 100% coverage, describing 'root' as the chapter library root directory containing the novels subdirectory. The description also mentions the novels folder, but it does not add any additional semantics or usage details beyond what the schema provides. Thus, 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 uses the specific verb '列出' (list) with a clear resource ('小说章节库中的全部作品', i.e., all works in the novel chapter library) and specifies the output includes chapter count and total word count. It clearly distinguishes from sibling tools like novel_read (which reads a specific work) or novel_chapters (which likely lists chapters within a 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 conveys clear context: this tool lists all works in the library, which is a high-level overview. However, it does not explicitly state when to prefer this over alternatives (e.g., novel_chapters for a single work's chapters) or any exclusions. The usage is implied by the purpose, which is clear enough for an agent to infer, but no explicit guidance is given.

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 a key behavioral trait beyond the schema: '只读不写盘（仅复用既有分析缓存）' – it is read-only and only reuses existing analysis caches. This is valuable because the tool name 'brief' doesn't imply read-only, and there are no annotations to carry this information. It also discloses that it aggregates from multiple sources. However, it doesn't detail what happens if the cache is missing or whether it can fail, so a 4 rather than 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph that front-loads the core value proposition ('开写包：一次调用装配出...') and ends with the usage directive. It packs a lot of information efficiently, but the long enumeration of contents makes it slightly dense to parse. The key usage guidance is at the end rather than the beginning, which is a minor structural flaw.

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 4 parameters, 100% schema coverage, and no output schema, the description covers the essential context: what it returns (the enumerated package contents), its read-only behavior, and when to use it. The main gap is that it doesn't describe the output format or how the returned package is structured, but since there is no output schema, the description partially compensates by listing the contents. It also doesn't mention error cases (e.g., missing chapter files), but this is a minor gap for an assembly tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds context for the 'budget' parameter by explaining compact vs full in terms of context-saving ('按小额截断以省上下文' vs '给全'), and for 'chapter' by explaining the 'next' default behavior. However, it doesn't add meaning for 'book' or 'root' beyond what the schema already says. The description's main value is in explaining the overall purpose, not the individual 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 uses a specific verb ('装配'/'开写包') and resource ('写这一章需要的一切'), then enumerates the exact contents (上一章结尾原文、本章大纲方向、人物卡、伏笔、世界观用语、六维风格基线、原著锚段、禁用清单、开写清单). This clearly distinguishes it from siblings like novel_read or novel_outline by stating it is a one-call assembly package rather than a single-purpose reader.

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 explicitly states when to use it: '写新章前应先调它' (call it before writing a new chapter), and explicitly tells the agent NOT to use individual tools instead ('而不是逐个工具去翻'). This is a direct usage directive with an alternative-avoidance instruction, which is the strongest form of 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?

With no annotations provided, the description carries the full burden and adds useful behavioral context: it explicitly marks the operation as read-only and discloses the collision-group hint behavior for duplicate chapter numbers. It does not cover ordering, error cases, or default root behavior, but it goes beyond a bare functional 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?

Two tight sentences: the first front-loads the action and output fields, the second adds the read-only and edge-case behavior. Every sentence adds value and nothing is redundant.

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 and no annotations, the description adequately explains what is returned and highlights an important duplicate-chapter behavior. It is mostly complete for a simple listing tool, though it omits details like ordering and behavior when the book does not exist.

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 both parameters ('book' and 'root'). The description does not add extra parameter-level meaning such as formats, defaults, or prerequisites, 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 uses a clear verb ('列出') and resource ('某部作品的全部章节'), and enumerates the exact fields returned. It distinguishes itself from reading/brief tools by focusing on the full chapter list, though it never explicitly names a sibling it is not.

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 choose this tool over alternatives such as novel_chapter_brief or novel_read. The description implies a listing use case but provides no explicit context, exclusions, or alternative routing.

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 behavioral burden. It discloses the output shape (contradiction candidates across four categories) which is genuinely useful, and '供修正' implies it only reports rather than edits. However, it never states that the operation is read-only, whether files are modified, or what happens on failure, so notable gaps remain for an un-annotated 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?

A single dense sentence that front-loads the purpose (continuity audit against the settings sheet) followed by the output categories. No filler, though the compact Chinese phrasing packs several distinct ideas into one clause chain.

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 does explain the returned artifact type (contradiction candidates), which is the key gap-filler. But it omits whether the tool mutates anything, what the settings sheet dependency means, and how the alternate modes interact, so it is adequate rather than 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 all five parameters (ooc, book, root, chapter, outline) are already documented in the schema, including the three alternate modes. The description adds the contradiction categories but no parameter-level syntax or default behavior beyond that, so 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 gives a clear verb+resource: audit continuity ('连贯性审计') by scanning the whole book against the settings sheet and emitting contradiction candidates. The listed categories (数字口径/人物缺场/别名/重复) make the scope concrete and distinguishable from siblings like novel_style_check or novel_plot. It does not name any sibling explicitly, so it stops short of 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?

Usage is implied rather than stated: the tool is for finding continuity contradictions 'for correction', which tells an agent the context (post-draft review). But there is no explicit when-to-use vs novel_style_check/novel_plot, no prerequisites, and no mention that the settings sheet must already exist. The three operating modes live in the schema, not the description.

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 behavioral disclosure burden and does disclose key traits: the plan/verify/mark semantics, the composition of each plan item, and the hard constraint that no actual sentences are generated. It implies mark is a state change, but it does not state whether changes persist or what side effects occur, which prevents a higher score.

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 dense sentences front-load the core purpose, then the action semantics, then the decisive boundary. There is no filler and no repetition of what the input schema already states.

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 moderate complexity of six parameters, three actions, no annotations, and no output schema, the description covers the plan output structure, action behavior, and inter-parameter relationships well. It does not specify the exact return shape of verify or error handling, but the schema covers individual parameter definitions.

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, but the description adds meaning by defining each action value, declaring plan as the default, and stating that mark requires both itemId and state while sourcing itemId from plan's returned items[].id. This goes beyond the plain schema property 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 opens by stating that the tool converts style diagnosis into a prioritized todo list, and enumerates exactly what each item contains (sentence position, current/target values, anchor passage, revision direction). It differentiates itself from siblings by declaring '只给方向不给句子' – it gives direction, not prose – which is a clear distinguishing boundary.

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 concrete per-action usage: plan generates the checklist and is the default, verify re-tests the current text, and mark requires both itemId and state. It also states the negative case (does not generate prose), but it does not name alternative sibling tools or specify the exact workflow ordering relative to style_check.

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 must carry behavioral disclosure. It usefully states that scan is a non-writing preview and apply performs the import, and that files can be copied or moved, but it omits important mutation details such as overwrite behavior, conflict handling, and permission requirements for a bulk-write operation.

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 packs a lot of information efficiently. The parenthetical mode summary is terse but functional; nothing is redundant or wasted.

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 7-parameter import tool with no output schema, the description covers the main workflow but omits the return format of scan, error behavior, and edge cases like duplicate book names. The schema descriptions compensate partially, but the description alone is not fully 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?

The input schema has 100% description coverage, so the baseline is 3. The description adds context about grouping and the scan/apply modes, but it does not expand on parameter syntax or default behavior beyond what the schema already documents.

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 (批量导入原稿件) and describes the mechanism: scanning a folder, identifying book/chapter names, grouping, and copying/moving to novels/<书名>/. This is clearly distinct from all sibling tools, none of which perform bulk import, though it does not explicitly differentiate itself from any sibling by name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly explains the two operational modes: scan for preview and apply for execution, giving the agent enough context to choose the right mode. It does not mention alternative tools or exclusions, but no sibling tool offers comparable functionality, so the guidance is effectively complete.

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 mentions the output format (excludes single characters) but doesn't disclose performance characteristics, size limits for 'top', or typical output structure beyond that one exclusion.

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?

One efficient sentence that front-loads the core action and appends a useful scope exclusion. 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?

Adequate for a read-only analysis tool, but as no annotations or output schema exist, the description could better explain return shape or constraints on 'top'. It's minimally viable but has clear gaps for an agent deciding between this and other novel analysis 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?

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds the behavioral note that 'chapter' is optional and that omitting it covers the whole book, but this is already implied by the schema's '可选' note.

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?

Clearly states the verb (统计 frequency) and resource (关键词 in a novel or chapter), distinguishing it from siblings like novel_summary or novel_sentence_analysis. The parenthetical about not including single characters is a useful scope detail, though it doesn't explicitly name an alternative tool.

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 this tool versus alternatives like novel_summary or novel_semantic_search. Usage is only implied by the description of what it counts.

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, and it does disclose two real traits: the default is to auto-assign the next chapter number, and the title is written as a Markdown H1. However, it omits conflict/overwrite behavior, required permissions, and what is returned after creation.

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 short sentences, front-loaded with the action and the notable default, with no filler. Efficient, though it could have used the space to cover the missing behavioral detail.

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 file-creating mutation tool with no annotations and no output schema, the description covers the happy path (book, root, optional title/content, auto chapter number) but says nothing about overwrite/conflict handling or the return value, leaving an agent to guess on edge 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 description coverage is 100%, so the baseline is 3. The description's mention of title and initial content merely repeats what the schema already documents for the title and content properties, adding no syntax or format detail beyond structured fields.

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?

States a specific verb and resource: creating a new chapter file for a given work, with the auto-numbering default noted. It is clearly distinguishable from sibling novel_chapters (which lists/reads chapters), though the description does not explicitly name any sibling to contrast with.

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 the default chapter-numbering behavior but gives no when-to-use guidance, prerequisites, or alternatives (e.g., when to use novel_chapters vs this tool, or what happens if the chapter already exists). Usage is only implied by 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 carries the full disclosure burden. It says materials are 'initialized, read, updated' but never states whether writes overwrite existing files, are idempotent, destructive, or require an existing directory — meaningful given this tool obviously mutates files on disk.

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 dense sentence front-loads the resource scope and then enumerates the artifacts, with no filler. It is efficient, though the enumeration is long and slightly list-like rather than prioritized.

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 an 11-parameter, 7-action tool with no annotations and no output schema, the description covers the scope of managed artifacts but not how the actions relate, what persists, or what a read returns. Adequate as a minimum but leaving gaps an agent would have to resolve from the schema alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including the action and file enums is already documented inline. The description reinforces the file categories but adds no format, default, or interaction detail beyond the schema. 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 gives a specific verb set (初始化、读取、更新) plus a concrete resource: the creative-material files under novels/创作资料/<书名>/. It enumerates the artifact types (创作设定/主要人物/次要人物/剧情大纲/钩子记录/创作状态卡), which maps well onto the file variants. It does not differentiate itself from the many siblings that also touch novel data, so it falls short of 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?

There is no statement of when to choose this tool over novel_read, novel_books, novel_chapters, novel_plot or novel_settings, all of which plausibly overlap. No prerequisites, no exclusions, no ordering guidance. Usage must be inferred entirely from the action enum in the schema.

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. '维护' hints at mutation, and the open/done statuses imply state changes, but the description does not disclose that add/update/done/delete persist changes, what data may be modified, or that graph is read-only. It does not contradict any annotation because none exist, but it leaves major behavioral traits unexplained.

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 clean sentence with no filler, and it front-loads the core resource type. However, it is so brief that it sacrifices behavioral context that would matter for a 13-parameter tool, so it is concise but slightly under-specified.

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 13 parameters, multiple action modes, and no output schema, this description is too thin. It does not explain the action lifecycle, when to use scan versus graph versus add/update/done/delete, or what a call returns. The schema covers parameter mechanics, but the description alone does not give an agent enough context to invoke the tool correctly in a real 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 100%, so the baseline is 3 even without parameter details in the description. The description adds only the open/done status vocabulary and does not meaningfully clarify any of the 13 parameters 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 identifies the resource (伏笔/剧情线登记表, a foreshadowing/plot-line registry) and the action (维护, maintain), and adds the open/done status model. It is clearly distinct from sibling tools like novel_style_check, novel_continuity_check, and novel_outline, though it does not explicitly name an operation like list/add/update.

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 about when to use this tool versus alternatives. The description only states what the registry is, not when an agent should choose it over related tools like novel_outline or novel_semantic_search. The use cases are implied by the name and action schema but not stated.

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 present, the description explicitly discloses the read-only nature of the operation ('不写任何文件、不改动任何数据'), which is essential safety information. It also states the output shape, though it does not cover error behavior or edge cases.

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 tight sentences with no filler; the main action and return value are front-loaded, and the read-only caveat is clearly separated.

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 read tool with no output schema, the description covers the operation, return format, paging strategy, and safety profile. Minor gaps like error handling and parameter interactions are not critical for invoking the tool 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 coverage is 100%, so the parameters are already documented. The description adds behavioral meaning to offset/limit by framing them as a way to read long chapters in segments, which goes beyond the raw schema text.

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 ('阅读某部作品的某个章节') and specifies the return value (line-numbered text with word count). This clearly differentiates novel_read from sibling list/summary tools like novel_chapters and novel_chapter_brief.

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 clear context for when to call the tool (read a chapter's body) and adds practical guidance for handling long chapters with offset/limit. It does not explicitly name alternatives or exclusions, but the use case is unambiguous.

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 does disclose useful behavior: local embedding (no external calls) and 0 token cost, which is genuinely valuable. However, it omits whether the operation is read-only, any scope limits (top max 10 is only in the schema), and pagination/traversal behavior across the book.

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 tight sentence with no padding, and the most decision-relevant facts (local embedding, 0 token, works without keywords) are front-loaded. It is appropriately sized for the amount of information conveyed.

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 4-parameter search tool with no annotations, the description covers what it does and its cost profile but leaves gaps: no statement of return shape or result ordering, no mention that root configures the chapter library, and no routing guidance against the keyword-search sibling.

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 all four parameters including the query examples and the top default/max. The description adds only the natural-language framing already implied by the query param description, so baseline 3 is correct.

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?

States a specific verb (语义检索) and resource (全书语义相关段落), and the clause '无关键词也能命中' implicitly frames it as the semantic counterpart to keyword search. The closest sibling, novel_keywords, is never named, so the agent must infer the routing choice from the description's phrasing rather than an explicit contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage is clear: use natural language when you lack exact keywords. But there is no explicit when-not guidance and no named alternative, even though novel_keywords is the obvious competing tool. For 15 sibling tools, an agent benefits from being told directly when this beats keyword search.

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 behavioral burden — it discloses two non-obvious traits: shared engine/cache with its siblings (cached results may be served across tools) and availability gated by a UI switch. The schema's fresh parameter hints at caching, but the description adds the shared-cache and configuration-gating facts beyond the schema. It stops short of describing return shape or failure conditions, which keeps this from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every segment earns its place: the front-loaded analysis-surface list, the bracketed routing rule, the sibling disambiguation, and the UI-switch caveat. It is dense rather than padded, and the bracket-delimited routing rule keeps the decision-critical information scannable despite overall length.

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 is a complex 8-parameter tool with no output schema, and the description covers the breadth of what it produces well. However, it does not describe the shape of returned data (e.g., what brief=true truncates or how results are keyed by chapter), and it omits prerequisites such as which books are analyzable even though novel_books exists as a sibling. Good enough for tool selection, slightly thin 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 100%, so the baseline is 3; the description's category enumeration (high-frequency templates, emotion curve, chapter-level rhythm sequences) maps loosely onto top, curveSegments, and chapter, adding mild output context that helps parameter understanding. However, it adds no syntax, format, range, or default information beyond the schema, so it does not exceed 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 specifies a concrete analytical verb (统计/分析) bound to a clear resource (某部作品或单章) and enumerates the full analysis surface: nine sentence-type categories, arrangement patterns, paragraph structure, sentence-length distribution, emotion curve, style fingerprint, and rhythm suggestions. It also explicitly distinguishes itself from novel_style_check and novel_style_report by question type, so an agent can identify it without opening schemas.

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 bracketed rule 【问「这本书是怎么写的」时用它】 gives the exact condition for calling this tool, and it names two sibling alternatives with their own trigger questions (novel_style_check=「我这一章写得像不像」, novel_style_report=「这本书是什么风格」), explicitly asserting they are different questions rather than duplicates. It also flags the UI-switch prerequisite and routes the agent to novel_sentence_config for status checks — full alternative and precondition 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the behavioral effect of each key setting: enabled controls whether the analysis is available, autoAnalyze controls active use during analysis, systemPromptMode and promptScene determine prompt injection and workflow selection, and leanWorkflow reduces tool calls and saves tokens. It does not cover every hidden side effect or permission concern, but the main configurable behavior is 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 front-loaded with the core purpose and uses parenthesized lists to compress a large amount of parameter semantics into a single sentence. Every clause contributes meaning, with no filler or redundancy, though the single-sentence structure is slightly dense and could benefit from tighter formatting.

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 an 11-parameter get/set tool with no annotations and no output schema, the description explains the core discretionary settings but omits several parameters like tools, features, styleTolerance, creationProfile, and creationProfiles. The schema's rich descriptions compensate for the omissions, but the lack of any statement about what get returns or how set affects current state leaves a meaningful gap in contextual guidance.

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 description coverage is 100%, so the schema already fully documents all 11 parameters, including nested objects and enums. The tool description adds only a compressed summary of five main switches and does not provide extra syntax, constraints, or validation details beyond what the schema gives. Thus 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 opens with a precise verb+resource statement: '查看或修改句式模式分析的开关状态' (view or modify switch states of sentence-pattern analysis). It clearly identifies the tool as a configuration getter/setter for a specific feature, distinguishing it from sibling tools like novel_sentence_analysis (which performs analysis) and novel_settings (general configuration).

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 clearly implies when to use the tool: whenever the author-agent needs to inspect or change sentence-pattern analysis settings such as enabled, autoAnalyze, systemPromptMode, promptScene, or leanWorkflow. It does not explicitly mention alternatives or exclusions, so it misses the top-tier routing guidance, but the usage context is obvious from the stated 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 carries the full behavioral burden for a 22-parameter mutation tool. It says nothing about delete being destructive/irreversible, permission or root-path requirements, whether scan/detect are expensive or non-idempotent, or what these operations return – a significant gap for a tool that writes and deletes 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?

A single dense parenthetical sentence front-loads the resource, tables, and actions with no filler. It is compact and scannable, though the nested-clause format is slightly harder to parse than a short sentence or two.

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 22-param tool the 100%-covered schema does the heavy lifting and there is no output schema to explain, so return values need not be described. What is missing is behavioral context (destructive delete, scan/detect cost, root/chapter prerequisites) that the schema cannot convey.

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 schema itself documents action enums, category 专用 fields, and per-table semantics in detail. The description's parenthetical mapping of the five tables adds a little framing but no syntax beyond what the schema already supplies, so baseline 3 is correct.

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 resource (设定管理) and enumerates the five tables plus the full action set (list/add/update/delete/scan/detect), so an agent knows exactly what domain it operates on. It does not, however, differentiate itself from any sibling like novel_keywords or novel_style_check, so the 4-tier is appropriate.

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 clarifies that the CRUD-style actions are grouped by category and that detect is worldview-specific and automatic, which implies usage. But it never states when to reach for this tool versus sibling tools (e.g., novel_keywords for keyword work) or any prerequisites, so guidance is only implied.

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 behavioral disclosure burden. It discloses the comparison methodology (style fingerprints against other chapters), the dimensions (句式分布/句长/情绪), and the output form (similarity and deviation list). It does not explicitly state side-effect freedom or error behaviors, but the analysis framing ('自检', '对比', '输出') makes the read-only nature reasonably clear.

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 compact sentence delivers the core purpose, then uses a dash to add the trigger phrasing and sibling routing. Every clause contributes: what it compares, how, what it outputs, and when to use 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?

There is no output schema, and the description only says the output is a 'similarity and deviation list' without detailing its structure or interpretation. However, for a moderate-complexity analysis tool with fully documented parameters and clear sibling routing, this is a minor gap rather than a blocking one.

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 input schema already documents all three parameters. The description itself does not add parameter-level semantics beyond what the schema 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 states a specific verb ('对比') and resource ('某章节与全书其他章节的风格指纹'), names the output ('相似度与偏差清单'), and explicitly distinguishes the tool from novel_fix_plan, novel_style_report, and novel_sentence_analysis. An agent can clearly understand what this tool does and how it differs from 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?

It provides an explicit trigger question ('我这一章写得像不像全书') and names three alternatives with their specific use cases ('可执行的改稿待办', '全书风格画像', '写作手法'). This leaves no ambiguity about when to use this tool versus 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?

With no annotations, the description carries the burden and does disclose the core behavior: aggregating measurements into a whole-book profile and the scope distinction from chapter-level judgment. However, it omits behavioral traits such as the 'get' action for reading saved AI judgments and the persistence side effect of passing aiJudgment, which are represented only in the 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 compact, front-loaded with the core concept, and every clause adds value — measurement content, usage trigger, and sibling exclusions. 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?

The description, combined with the thoroughly documented schema, gives an agent enough context to invoke the tool: it defines the output (whole-book style profile), lists the data dimensions, and clarifies which siblings to choose instead. It doesn't detail the precise return structure, but the description's scope and the schema's parameter guidance make this a minor 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 description coverage is 100%, so the baseline is 3. The description adds high-level context about the 6 measurement dimensions but does not need to explain individual parameters because the schema already documents book, root, brief, action, and aiJudgment clearly.

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 deliverable ('风格画像报告'), states what it aggregates (6 dimensional measurements), and explicitly differentiates it from novel_style_check and novel_sentence_analysis. An agent can identify the tool's purpose and distinguish it from key siblings without opening the schema.

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 gives an explicit trigger ('问这本书是什么风格时用它') and tells the agent what this tool is not for. The alternative tools are named (novel_style_check for single-chapter, novel_sentence_analysis for technique breakdown), so when-to-use versus alternatives is 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 carries the full behavioral burden. It adds only that summaries are model-generated and plugin-stored; it says nothing about whether delete is destructive, whether add overwrites existing summaries, what permissions are needed, or how failures behave — the schema's 'add=新增/覆盖' hint never surfaces in the prose.

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 short clauses plus an operation list; the resource and purpose are front-loaded and nothing is padded. It is slightly cryptic in the second clause but efficiently sized.

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?

A seven-parameter tool with a destructive delete action, no annotations, and no output schema needs more than this: it should cover mutation semantics, overwrite behavior, and return shape expectations. Those gaps are left entirely to the 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 description coverage is 100%, so all seven parameters are already documented in the input schema, which sets the baseline at 3. The description restates the action set and the '按章节' scoping but adds no format, default, or interaction detail 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 names a specific resource (章节摘要) and enumerates the operations it supports (add/update/get/list/delete), so an agent knows this is a CRUD tool over per-chapter summaries. It does not, however, contrast itself with siblings like novel_chapters or novel_plot, which also manage chapter-scoped content, so the boundary is left to inference.

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 gives a use rationale — read summaries to recall plot and avoid re-reading chapters — which implies when the tool is valuable. But there is no explicit when-to-use/when-not guidance and no named alternative for the overlapping cases (e.g. novel_plot or novel_chapters), so usage is only implied.

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