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

With no annotations, the description carries the burden well: it discloses defaults (dry_run=true, mode=draft, interval 2000ms), rate-limiting protection, continue_on_error semantics, and that publish puts chapters into an unmodifiable review state. It stops short of describing the actual return payload for a non-dry-run upload.

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?

Front-loads the core identity with '(核心工具)', then enumerates source types and the dry-run gate in a compact progression. Dense but every clause carries operational meaning; slightly long, though nothing is obviously 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?

For an 11-parameter mutation tool with no annotations and no output schema, the description covers safety (dry-run first, auth failure aborts, rate limiting) and the key defaults. It could say a bit more about what a real upload returns, but it is sufficient to invoke 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 already 100%, so baseline is 3; the description adds real value by explaining the three source layouts, how range and volume_map are used (including unmapped-volume fallback to volume_id/default), and the draft-vs-publish consequence of mode.

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+resource (批量上传章节) and immediately distinguishes itself from the single-chapter sibling by emphasizing batch scope and the three accepted source layouts. An agent can tell this apart from upload_chapter without inspecting 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?

Clearly prescribes the workflow: dry_run=true first to preview the plan, then dry_run=false to actually upload; mode=draft by default, publish only when ready for review. It does not explicitly name upload_chapter as the alternative for a single chapter, leaving that inference to the 'batch' framing.

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?

该描述披露了真实的行为细节：凭证来自 auth.json 或环境变量，并会执行一次网络请求以验证。这很有价值，因为此工具没有提供任何注释。但它没有说明失败模式（当登录态无效时，是抛出错误、返回 false，还是无返回？）——对无注释的工具来说，这是最后一层透明性缺口。

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?

两句话，没有填充内容：首先是行为，其次是返回内容。父级说明中的实现细节（auth.json/环境变量、一次书单调用）直接位于事实之后，而有用的内容没有任何被埋没。

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

没有输出 schema，但描述用一句话说明了返回内容（账号下的小说数量概览），这大约是智能体所需的信息。对于一个简单的零参数验证器来说，这是完整的；只有失败时的行为没有说明。

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

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

该工具接受 0 个参数，因此不存在需要补充的语义，这就是零参数工具的基准分。描述也没有声称存在可选参数，这会与空 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?

该描述包含明确的动词 + 资源（检查 ... 登录态是否有效），并明确说明其范围（凭证来自 auth.json 或环境变量，通过一次书单接口调用来验证），这将其与同级工具（如 list_books、list_chapters）清楚区分开；后者假定认证已存在，但这个工具自身会验证认证。

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

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

用途是隐含的——它是一个预检工具——但描述从未明确说“在调用其他工具之前使用此工具”，也没有说明任何排除条件或在其他同级工具中的替代方案。由于使用场景相当明显，该描述仍足够作为最低限度的可行说明，但智能体只能推断其前置作用。

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

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

With no annotations, the description must carry the full behavioral load. '列出' implies a safe read and the account scope is stated, but nothing is said about result size, ordering, pagination, or what happens on accounts with many books — gaps that matter for a list-all 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?

Two short sentences, zero filler. The purpose and returned fields come first, with the actionable usage note second.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description compensates by naming the four returned fields (book_id, 书名, 字数, 状态), which is exactly what an agent needs to chain into batch_upload. The remaining unknown is result volume/pagination, a minor omission for a zero-parameter 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies no filtering is available (it lists everything under the account).

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 (列出), resource (所有小说), and scope (账号下), which cleanly separates it from list_volumes and list_chapters that operate on narrower resources. The parenthetical enumeration of returned fields further pins down what 'list' means here.

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?

Gives a concrete precondition tied to a sibling: run this before batch_upload to obtain book_id. It stops short of naming when NOT to use it or pointing to alternatives, so it is strong context rather than a full routing rule.

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

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

No annotations are present, so the description carries the full burden. It discloses the returned fields and the read-only listing intent, but says nothing about pagination, ordering, result limits, or whether all chapters are always returned.

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 sentence, front-loaded with the action and scope, followed by the return fields and the purpose. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read tool with full schema coverage and no output schema, the description covers action, scope, return fields, and intent. Only the result-set behavior (pagination/completeness) is unaddressed.

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 both parameters, including the optional book_id default and the volume_id fallback that lists all volumes, are already documented in the schema. The description adds no parameter detail beyond what the schema provides, so the 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?

A specific verb (列出) and resource (章节) plus the parent scope (某分卷下) and the returned fields (item_id、标题、状态、字数). It's clearly distinguishable from list_volumes/list_books, though it doesn't name a sibling explicitly.

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 clear use context: confirm which chapters are already uploaded and avoid duplicates, which points at upload_chapter/batch_upload workflows. It stops short of explicit when-not-to-use or naming the alternative tools.

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

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

With no annotations, the description must carry the behavioral load. '列出' implies a safe read, and the returned fields are disclosed, but it says nothing about permissions, behavior for non-multi-volume books, or what happens when book_id is omitted.

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 with no filler; the purpose and returned fields come first, followed by the use case.

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 read tool with one documented optional parameter and no output schema, naming the returned fields makes the definition sufficient. Only edge-case behavior (empty book, invalid book_id) is left unaddressed.

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 single optional book_id already documents its default to the currently selected book. The description adds no further parameter meaning, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('列出小说的分卷') and even names the returned fields (volume_id, 卷名), so the agent knows exactly what it gets back. It does not explicitly contrast with the nearby list_chapters sibling, which keeps it at 4 rather than 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?

It gives a concrete usage condition: needed for volume mapping when batch-uploading multi-volume works, which points the agent toward batch_upload as the downstream consumer. It stops short of stating when not to call it or naming alternatives explicitly.

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 behavioral burden, and it does usefully disclose that nothing remote is touched ('不动任何远端数据') — a real safety signal against the mutating siblings. It does not say what the call returns (an HTML string? a rendered preview?) and there is no output schema to cover that, leaving a meaningful gap.

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, front-loaded with the transformation, zero filler. It is arguably compressed to the point of omitting needed detail, but nothing in the text is 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 two-param, non-mutating local preview tool with full schema coverage, the description supplies the missing behavioral piece (no remote side effects) and the intent. The remaining gap — no statement of the return value despite no output schema — is the only thing an agent would still wonder about.

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 both parameters and the baseline is 3. The description adds nothing about the file-vs-content relationship, which matters here since both are optional and the schema descriptions ('或本地稿件路径') do not establish precedence.

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 transformation (plain text → 番茄正文 HTML with <p> paragraphs) plus the purpose (看效果, 格式自查). That is enough to separate it from the sibling upload/update tools, which all operate on remote chapter data. It never names a sibling explicitly, 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?

'用于格式自查' implies the usage context but never states the triggering condition (e.g. run before upload_chapter / batch_upload to verify formatting) or any exclusion. The agent has to infer when to reach for this instead of uploading directly.

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 does well: it discloses overwrite (destructive) semantics, the draft-only state restriction, and the concrete platform failure signal (-3027). It omits what happens to omitted optional fields (e.g., title/volume preserved or cleared) and any permission/auth notes.

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 compact sentences with zero filler: the operation and key first, then the state constraint and error. Nothing is restated or padded.

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 mutation tool with no annotations and no output schema, it covers the critical risks (destructive overwrite, draft-only restriction, error code). It stops short of describing the response shape or the effect on optional fields left unspecified, which an agent would want before calling it.

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 goes beyond it by explaining where item_id comes from (list_chapters) and reinforcing that this is an overwrite keyed on that id. The remaining six optional parameters are left entirely to the schema, where file-vs-content exclusivity is already documented.

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 mode ('覆盖更新', full overwrite) on a specific resource ('已存在的章节'), and identifies the chapter by item_id sourced from the sibling list_chapters. This distinguishes it from upload_chapter, which creates new chapters.

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?

Gives an explicit precondition and exclusion ('仅草稿可改；已提交审核的章节改不了') and points to list_chapters as the way to obtain item_id. It never names upload_chapter as the alternative for non-existing chapters, so the routing guidance is strong but not exhaustive.

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 burden and does well: it discloses the safe draft default, that publish submits for review, that publish_time schedules publishing, and that file mode auto-parses the title. It omits edge cases such as auth requirements, failure behavior, or what happens if a chapter already exists.

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

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

The description is compact and front-loaded: the core action comes first, followed by input alternatives and mode behavior. Every sentence contributes useful calling 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?

For an eight-parameter mutation tool with no output schema, the description covers the essential input modes, defaults, and publish semantics. Remaining gaps, such as auth requirements and error behavior, are minor but prevent a perfect score.

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

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

Schema coverage is already 100%, so the schema documents all eight parameters. The description still adds cross-parameter meaning by explaining the title+content vs. file alternatives, the mode default, and scheduling via publish_time.

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: upload a single chapter. The word '单章' distinguishes it from the sibling batch_upload, and the two content-input paths make the tool's scope immediately clear.

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 valid content modes and the draft-vs-publish behavior, including the safe default. It does not explicitly name alternatives such as batch_upload or update_chapter, so it falls short of full when-to-use/when-not guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the key stateful behavior — setting a default book_id for subsequent tools — but does not clarify whether it overwrites an existing default, how long the default persists, or what happens if the book_id is invalid.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the action and the resulting default behavior immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter context-setting tool with full schema description coverage and no output schema, the description is nearly complete: it explains the action and its effect on later calls. A minor gap is the lack of detail about lifecycle or overwrite behavior, but the essential information 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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that the book_id parameter becomes the default for subsequent tools when they omit it, which clarifies the parameter's role as persistent context rather than just a target identifier.

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 (设置 / set) and resource (book_id), and it clearly differentiates the tool from sibling tools by explaining that it establishes a default context for subsequent operations rather than performing a list or upload action.

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 clear usage context: call this to set the current operation's book_id, and later tools will use it by default if they are not given a book_id. It does not explicitly state when not to use it or name alternatives, but the guidance is sufficient for a simple context-setting tool.

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