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 and does so well: it warns that the editor auto-saves while typing (a real destructive-risk disclosure), states that confirm=false is read-only, and explains that content can come from content/file_path/article_id with article_id taking priority. This is exactly the safety-relevant context an agent cannot infer from the schema alone.

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 action and inputs in sentence one, then the content sources, then the confirm warning. Dense but each clause earns its place; the emoji and bolding aid scanning rather than padding.

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 9-parameter mutation tool with no output schema and no annotations; the description covers the risky behaviors, input sources and publishing mode. It does not mention auth prerequisites (login_qimao/set_qimao_cookies) or rate/pagination concerns, but as a fire-and-report action tool it is largely complete.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds usable meaning: the content/file_path/article_id triple is framed as a '三选一' choice with priority, and confirm/scheduled_time are tied to concrete behaviors. This goes modestly beyond the per-parameter 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?

States a specific verb and resource up front ('向指定书籍新增一个章节') and enumerates the inputs needed (章节序号 + 标题 + 正文). An agent can immediately separate this from list_chapters_qimao, update_chapter_qimao or delete_chapter_qimao without opening a 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?

Explicitly explains the two operating modes: confirm=false '只打开页面读现状 + 截图，绝不填充' versus confirm=true '才填入并提交'. This is precisely the when/when-not guidance an agent needs to avoid an unintended publish. The scheduled_time publishing path is also called out.

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 substantial work: it discloses sequential ordering, rate limiting, failure isolation (单章失败不中断), per-chapter results, and the draft-avoidance rationale for confirm=false. It omits auth prerequisites and the irreversibility/side effects of a real publish, which login_qimao-style context only implies.

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 clauses, front-loaded with the core action, then the failure/return behavior, then the confirm caveat. Dense but every clause carries information; minor density from stacked modifiers keeps it just under 5.

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 mutation tool with no annotations and no output schema, the description covers ordering, rate limiting, failure semantics and the dry-run mode well. Remaining gaps are the result format (返回逐章结果 is named but not defined) and the book_id/novel_id resolution, though the latter is documented in 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 coverage is 100% (baseline 3), and the description adds meaningful semantics beyond the schema text: confirm=false does not merely skip publishing, it dry-runs only the first chapter to avoid accumulating drafts, and rate limiting is tied to the interval between chapters.

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 (待发布章节 from 本地文稿库), plus scope details: selects chapters in chapter-number order, rate-limited, sequential. It clearly distinguishes itself from the single-chapter sibling add_chapter_qimao by being the batch path.

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 explicit context: use it to pick 「待发布」 chapters from the local library, and use confirm=false to dry-run only chapter 1 without leaving drafts in the backend. It does not explicitly name add_chapter_qimao as the alternative for single uploads, so it stops short of full 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?

With no annotations, the description carries the full burden and does well: it discloses that detection is local with no network access and no quota consumption, and lists the specific analyses performed. It stops short of describing the result shape or what the similarity/threshold verdicts mean in practice.

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?

Purpose is front-loaded and the sentence is dense without filler; the offline/no-quota clause earns its place by reassuring the agent about cost. Slightly long with several comma-separated checks, but no wasted sentences.

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

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

No output schema and no annotations exist, so the description should ideally convey what the tool returns (scores, flags, verdicts). It fully describes inputs and the checks performed but leaves the return format unspecified, which is the main remaining gap for an analysis 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 schema already documents all three parameters including the 二选一 constraint between content and article_id, which the description merely restates. It adds no syntax or format detail for threshold beyond what the schema provides, 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?

States a specific verb+resource (本地原创性检测) and enumerates exactly what is checked: n-gram similarity against the manuscript library, self-repetition, cliché density, dialogue ratio, paragraph uniformity, and word-count threshold. None of the sibling tools perform originality analysis, so the resource is unambiguous.

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

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

It clarifies input selection — '用 article_id 或直接传 content' — and notes the operation is offline and quota-free, which tells the agent it is safe to run repeatedly. However, it gives no explicit when-to-use guidance (e.g. before publishing or saving) or workflow context relative to save_article/publish tools.

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

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

With no annotations, the description carries the full burden and does well: it discloses that it drives a real page, that field matching is by label text, that unmatched fields are surfaced in 'missing' rather than silently dropped, and that the default is a non-mutating dry run. It omits auth requirements and whether a successful create is idempotent or reversible.

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 action, then a caveat about label-based matching, then the confirm default — a sensible ordering. Three dense sentences with little waste, though the warning line is slightly verbose.

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 10-parameter mutation tool with no annotations and no output schema, the description covers the most important unknowns: dry-run default, submit behavior, and how unmatched fields are reported. It leaves out the login/session prerequisite and the effect of register_local, but the core call contract is clear.

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 ten parameters including gender encoding and the confirm default. The description repeats book_name as required and the gender mapping but adds little syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource (驱动真实建书页填表并提交 / creates a book on the Qimao author backend), and the scope is distinguishable from siblings like update_book_info_qimao, create_short_story_qimao, and list_books_qimao. An agent can tell what this does 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?

Gives explicit operating context through the confirm flag: confirm=false only opens the page to read status and screenshot, confirm=true actually fills and submits. It does not, however, state when to prefer this tool over siblings (e.g. create_short_story_qimao) or note the login prerequisite implied by login_qimao.

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 the dry-run default, that nothing is written without confirm=true, and that the word-count range is advisory only (提示不硬拦). It omits prerequisites such as login/auth and what is returned on submission.

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 sentences ordered by importance: action, content sources, advisory limits, then a prominent warning about the confirm default. Slight redundancy between '以平台实际规则为准' and '本工具只提示不硬拦', but nothing extraneous.

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 mutation tool with no annotations and no output schema, the description covers the critical behavioral risk (accidental submission) and the content input modes. It stops short of describing what the tool returns on success or what auth state is required.

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 baseline is 3; the description adds value beyond the schema by explaining the practical word-count range (3000–100000, sweet spot 10k–30k) and reinforcing that confirm=false means no write at all. Content-source precedence is only mirrored from the schema, not extended.

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 concrete verb and resource: fill the 新建短篇 form on the Qimao author backend and optionally submit. The resource (short story) is distinctive enough to separate it from create_book_qimao, but no sibling is named explicitly, so differentiation is left implicit.

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 when-to-use rule through the confirm flag: confirm=false opens the page, reads current state and screenshots without filling or submitting; confirm=true fills and submits. It doesn't route the agent to alternatives such as publish_short_story_qimao or update_book_info_qimao when a short story already exists.

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. It discloses two important traits: the operation does NOT touch the Qimao backend, and confirm defaults to a non-destructive preview. It stops short of stating reversibility or permission requirements, but the safety-critical scope and dry-run behavior are well covered.

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 clauses, front-loaded with the action and scope, then the confirmation default. Every phrase earns its place with zero redundancy or filler.

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

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

For a low-complexity tool (2 params, 1 required, no nested objects, no output schema), the description covers what is affected (local only) and the confirmation flow. Only minor gaps remain, such as error behavior and reversibility, which is acceptable given the tool's simplicity.

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 article_id and confirm. The description restates the confirm=false preview semantics, adding only marginal meaning beyond the schema's '是否真正删除，默认 false'. Baseline 3 applies since the schema does the heavy lifting.

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 crucially clarifies scope with '不影响七猫后台', which distinguishes it from the many *_qimao delete tools (delete_short_story_qimao, delete_chapter_qimao) in the sibling set. An agent can tell this operates on the local store only.

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

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

The description implies the intended flow ('默认 confirm=false 只预览') so an agent understands the preview-then-commit pattern, but it never states when to choose this over the related delete_short_story_qimao or delete_chapter_qimao siblings, nor any prerequisites. 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.

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 flags the operation as destructive ('破坏性'), discloses that the default confirm=false only previews plus screenshots, and that confirm=true performs the actual deletion. It omits whether deletion is reversible or what happens to chapter content, but the safe-default preview mechanism is a genuinely valuable disclosure.

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 with the destructive warning front-loaded ahead of the confirm semantics. No filler, and the most safety-critical information comes first.

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 destructive tool with no annotations and no output schema, the description covers purpose, danger level, and the preview-vs-execute switch adequately. It could add irreversibility or auth context, but nothing essential for correct invocation is missing.

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 goes beyond the schema by explaining the consequence of confirm=false (preview + screenshot), which the schema only labels as '是否真正删除'. This adds real meaning to the confirm parameter, though headless is left entirely to 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?

States a specific verb and resource ('删除指定章节' / delete the specified chapter), which cleanly separates it from siblings like update_chapter_qimao, add_chapter_qimao, and delete_article. An agent can identify the operation 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?

The two-mode confirm behavior implies when the tool is safe to call, but there is no explicit guidance about when to choose this over alternatives such as update_chapter_qimao, nor prerequisites (auth, book ownership). Usage is inferable rather than 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, the description carries the full burden and does disclose the most important trait: it is destructive and defaults to a non-destructive preview (confirm=false), only deleting when confirm=true. It still omits whether deletion is reversible, what permissions are needed, and what the preview returns.

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 the destructive warning front-loaded and the confirm behavior immediately after. No filler, and the highest-risk information appears first.

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 destructive 3-parameter tool with no annotations and no output schema, the safety-critical behavior is covered. Minor gaps remain around reversibility and the preview payload, but an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so book_id, confirm and headless are already documented; the description's confirm explanation largely repeats the schema text. Baseline 3 is appropriate since the schema does the heavy lifting.

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 (删除) plus the exact resource (短篇作品或草稿), which cleanly separates it from the sibling delete_chapter_qimao and delete_article tools. An agent can pick this tool without inspecting 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?

Usage is implied by the destructive tag and the confirm flow, but the description never says when to choose this over the sibling delete tools or what preconditions apply. The confirm semantics read as parameter behavior rather than selection 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?

无 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?

单句密集表达，目的前置，随后依次交代产物形式、适用场景、默认行为和离线属性，无冗余。

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?

无 output schema，描述已说明返回值（绝对路径）和关键默认行为，对 4 参数工具而言信息基本充分。仅未覆盖文件覆盖/错误处理等边界情形。

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

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

schema 覆盖率达 100%，参数含义已由 schema 完整表达。描述补充了格式取值 (txt/md) 和默认带书名的行为，与 include_novel_title 默认值一致，但基本是对 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?

States a specific verb (导出)、resource (本地文稿) 和输出形态 (txt/md 文本文件) 并说明返回绝对路径。明确指出产物可粘贴到七猫作者后台，足以与 save_article、import_articles_from_dir 等兄弟工具区分。

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?

「适合人工发布流程」点明了使用场景，与 batch_publish_chapters/publish_short_story_qimao 等自动化发布工具形成对照。语境清晰，但未显式点名替代工具或说明何时不该用。

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 behavioral burden. It usefully states that full text including body is returned, but gives no not-found/error behavior or permission context.

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

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

Single front-loaded sentence with no filler; the retrieval key and returned scope are stated 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-param read tool with no output schema, the description states the main return content. It omits error handling and auth, but those are minor for this scope.

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 article_id is already documented. The description repeats the lookup key but adds no format or source details 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?

States a specific verb ('取回') and resource ('本地文稿全文（含正文）') keyed by article_id. This distinguishes it from sibling list_articles, which lists articles rather than fetching full text by ID.

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 when-to-use or alternative-tool guidance. The required article_id implies retrieval when an ID is known, but the description never mentions list_articles or when not to use this tool.

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, so the description carries the burden, and it does usefully disclose the read-only nature and the caveat that returned field names depend on the platform's actual response. It does not mention auth/cookie requirements (relevant given login_qimao/set_qimao_cookies siblings), pagination, or result size for the 'all' scope.

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 dense sentence, front-loaded with the operation and its read-only nature, then the scope semantics in escalation order. No filler or repetition; every clause earns its place.

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

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

With no annotations and no output schema, the description adequately covers read-only safety, scope selection, the book_id dependency, and the field-name caveat. It is slightly thin on the date-range parameters and on auth prerequisites for a tool that clearly needs a logged-in session.

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 genuine meaning: the semantics of each scope value and the cross-parameter dependency that 'all' requires book_id. The month/start_date/end_date params are left entirely to 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?

States a specific verb+resource (读取收益数据 / read earnings data) and immediately declares it is a read-only HTTP operation, which separates it from the many mutation siblings. It does not name or contrast with the closest alternatives (get_book_statistics_qimao, get_stats), so an agent still has to infer which earnings/stats tool to pick.

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 escalation ladder: summary (default) for monthly settlement, detail to add subscription breakdown, all to add daily earnings. That is real when-to-use guidance beyond the terse enum. It stops short of naming alternatives or stating when NOT to use it (e.g., vs get_book_statistics_qimao).

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

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

With no annotations, the description carries the full burden; it usefully discloses that this is a read-only HTTP call requiring no browser session, which is real behavioral context. However it says nothing about rate limits, pagination, date-range defaults, or error behavior for an unspecified/private book_id.

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, front-loaded with the core action, that packs scope semantics and the read-only/no-browser caveat without a wasted clause.

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 statistics tool with no output schema, the description compensates by noting that field names follow the platform's actual response and pointing to the qimao://publish-rules resource for metric definitions. It stops short of describing the response shape or date-range behavior, but an agent has enough to invoke it 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, but the description adds genuine meaning beyond the terse schema enum by explaining what each scope value actually returns (overview, daily trend, or both). start_date/end_date are left entirely to the schema, keeping it just short of a 5.

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 enumerates the three modes it can return. An agent can tell it apart from list/create/update siblings, but the description does not differentiate it from the overlapping get_stats or get_book_income_qimao tools, which also return G七猫 statistics.

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 scope enumeration (detail vs trend vs all) implicitly guides mode selection, but there is no explicit statement of when to prefer this tool over get_stats or get_book_income_qimao, nor any stated prerequisite (e.g., must be logged in or have book access). Usage is implied rather than prescribed.

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 delivers real behavioral context: read-only paths go over pure HTTP while write operations require browser readiness, and the call returns remediation guidance. It does not disclose the cost/side effect of verify_login opening a real browser (time, resource use), which is the main 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 dense sentences that are front-loaded with what is checked, followed by the actionable interpretation of each flag. No filler, no repetition of the tool name or title.

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, so the description must explain return semantics; it does cover the two critical booleans (ready, browser_ready) and mentions remediation guidance. It leaves unaddressed what other diagnostic fields (cookie/driver detail, guidance structure) appear in the response, but it is sufficient for correct 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% and the single parameter verify_login is fully documented in the schema, so the baseline of 3 applies. The description never mentions verify_login and adds no meaning (e.g., that it slows the check or opens a browser) beyond what the schema already states.

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?

Names the specific verb (检查/self-check) and the concrete resources it verifies: cookies, browser driver, and backend reachability. It also states that it returns remediation guidance (补齐指引), so an agent knows this is a diagnostic/readiness gate rather than a data-retrieval tool, clearly distinguishing it from the login_qimao / set_qimao_cookies 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?

Explains the practical consequence of each result flag — 'ready=true 时列表/统计类工具即可用' and 'browser_ready=true 时写操作才可用' — which effectively tells the agent when the sibling tools are safe to call. It stops short of an explicit instruction such as 'call this before any write operation', so guidance is strong but implied rather than prescriptive.

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 the key behavioral trait by stating '(只读 HTTP)', signaling a non-mutating read, but it says nothing about authentication, rate limiting, or error behavior for an invalid book_id.

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

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

A single front-loaded sentence with the read-only qualifier in a compact parenthetical. Nothing is wasted and the resource is identified 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?

With no output schema and no annotations, the description usefully enumerates the main returned fields (title, word count, category, status) and marks the operation as read-only. It is nearly complete for a one-parameter read; only error/not-found behavior is left unspecified.

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

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

Schema coverage is 100% and there is only one parameter, whose schema description ('短篇 book_id') matches what the description implies. The description adds no extra format or sourcing detail, 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?

States a specific verb (读取) and resource (某篇短篇作品) and even enumerates the returned metadata fields (标题/字数/分类/状态), which makes it clearly distinct from the bulk list_short_stories_qimao. It stops short of naming that sibling explicitly, so an agent must infer the singular-vs-list split.

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

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

Usage is only implied: reading a single story when a book_id is already known versus listing all stories. There is no explicit when-to-use/when-not statement and no mention of where the required book_id comes from (e.g. list_short_stories_qimao).

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. It usefully discloses that the operation is a read-only HTTP call and that remote adds a second backend read, but it omits auth requirements (many siblings require login_qimao/set_qimao_cookies), failure behavior, and any cost/latency note for the network path.

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-loaded with the core purpose (汇总 local data) and appending the conditional remote behavior. Nothing is redundant, though the dense packing of multiple resources slightly reduces scannability.

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-optional-boolean tool with no output schema, the description covers purpose and the remote flag adequately. It nonetheless leaves the auth/prerequisite context for the network path unstated, which matters given the surrounding login/cookie siblings.

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 baseline 3, and the description adds real meaning beyond the schema by specifying that remote triggers reading the actual long-form and short-form lists from Qimao rather than just any backend data.

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 (汇总/summarize) over a specific set of resources (本地文稿库/任务/登记 + 环境自检) and clarifies the remote branch. It does not, however, explicitly differentiate itself from statistics siblings like get_book_statistics_qimao or get_book_income_qimao, so an agent must infer the distinction.

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

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

Usage is only implied: the agent learns that remote=true adds backend reads, but there is no statement of when to prefer this general summary over the dedicated statistics/income tools, nor any prerequisite (e.g., login/cookies) for the remote path.

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 full load and discloses substantial behavior: parse priority (in-file heading over filename), metadata/markdown stripping, and the overwrite rule (same novel+chapter overwrites body but preserves status/publish time), plus 'no network'. It leaves return/preview output format and malformed-file handling unstated, so not quite 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?

Front-loads the path pattern that anchors the whole operation, then layers parse rules, overwrite semantics, locality, and defaults in dense, non-redundant sentences. It is longer and information-dense but nothing is 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 6-param, no-annotation, no-output-schema batch tool, it covers the key behaviors an agent needs (what it touches, how it parses, what it preserves, that it's offline, preview default). Only the shape of the preview/result and edge-case errors are 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%, so the schema already documents all six parameters. The description reinforces a few (dir inference, confirm=preview, default overwrite) but adds no syntax or format detail beyond those structured descriptions; 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?

States a specific verb (批量同步进本地文稿库) and a concrete resource (磁盘章节稿), including the exact glob-like path pattern `小说/<书名>_<书号>/章节/第NN章_标题.md`. This clearly separates it from single-item siblings like save_article/export_article, which an agent can distinguish without opening any 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?

Gives clear operational context: dir can be omitted and is then inferred from novel_id, and confirm defaults to false so it only previews. It does not explicitly name an alternative (e.g. save_article for single in-body saves) or state when-not-to-use, 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.

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

With no annotations, the description carries the full burden. It usefully discloses one behavioral trait — results exclude full body text — but says nothing about pagination, default ordering, result limits, or what happens when all filters are omitted (0 required params).

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 front-loaded sentence that states the filters first and the scope caveat last, with no filler. Every clause carries 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?

No annotations and no output schema means the description must carry safety, defaults and return-shape information — yet it gives a single line. An agent still cannot tell whether the listing is paginated, what fields each entry contains, or how many results to expect, which matters for a 3-param list tool with all parameters optional.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning. It confirms that kind, novel_id and status are filters, but adds no semantic detail (no explanation of the kind/status values, no statement that they are optional or how they combine). Baseline for low coverage is not met fully, but the filter framing is more than the bare property names.

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 and resource ('列出本地文稿库条目') plus the filter dimensions, so an agent knows it returns library entries rather than content. It does not, however, name or contrast itself with the nearby siblings (list_chapters_tomato, list_short_stories_tomato, list_novels_tomato), so sibling differentiation 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?

Filter usage is implied by naming kind/novel_id/status, and the '(不含正文全文)' clause hints that get_article is the tool for full text. There is no explicit when-to-use or when-not-to-use statement, and no mention of how this local listing relates to the *_tomato listing 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?

No annotations are provided, so the description must carry the behavioral burden. It usefully discloses the read-only HTTP nature and the fact that the result is a set of selectable values, but says nothing about authentication prerequisites, caching/freshness, failure modes, or result shape. Read-only disclosure is real value, but for an annotation-free tool more is expected.

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

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

A single front-loaded sentence stating what is read, its read-only nature, and why it exists. Every clause earns its place; no padding.

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

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

For a zero-parameter, no-output-schema lookup tool, the description covers what is fetched and its downstream purpose, which is enough for an agent to call it correctly. Return-shape details are absent but arguably unnecessary for this simple case.

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 per the rubric the baseline is 4. The description correctly implies no input is needed to fetch the option lists.

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?

Names a specific verb+resource: reading Qimao backend book categories and tag options, explicitly quoted as the set of selectable values. This distinguishes it from list_books_qimao (existing works) and reasonably from list_genres (genre taxonomy only), though the relationship to list_genres is left implicit.

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?

States clear usage context: '供建书 / 改作品信息时选值' pins it to the create_book_qimao / update_book_info_qimao workflow. No explicit exclusions or when-not-to-use guidance, so it falls 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.

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 read-only HTTP access with no browser requirement, explains cursor-based pagination via next_id, and flags the sync_local side effect that writes into the local novel registry. It stops short of noting auth/permission prerequisites for the backend read.

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?

Dense and front-loaded: purpose first, then kind behavior, pagination mechanics, the sync side effect, and the transport note. Every clause adds information, though the kind default and sync_local constraint duplicate the schema.

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 list tool with no output schema, the description covers the essential return contract by naming next_id as the cursor and book_id as the payload. Return field details are thin but adequate for correct 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 description coverage is 100%, so all three parameters are already documented in the schema, including the kind enum, cursor semantics, and the kind=long restriction on sync_local. The description largely restates this, so the 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?

States a specific verb+resource: reading the author backend's real works list to obtain real book_id, with the kind split for long/short. It is clear what it does, though it never explicitly distinguishes itself from the sibling list_short_stories_qimao, which an agent might reasonably confuse with the kind=short path.

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 use case (fetch real book_id) and states that sync_local applies only to kind=long, but gives no explicit when-not guidance or routing against siblings like list_book_options_qimao or list_short_stories_qimao. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the full burden; it usefully discloses read-only nature (只读 HTTP) and the return payload (titles, word counts, statuses, volume list). It omits pagination behavior, auth requirements, and rate limits, so it is adequate but incomplete for an unattended read 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 with the core action, returned fields, and purpose front-loaded; every clause carries information. It could shed little, though the run-on structure is close to overpacked.

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 four-parameter read-only list tool with no output schema, the description covers what is read, what is returned, and the read-only guarantee, which is enough to call it correctly. Only pagination semantics remain 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%, so the schema already documents book_id, page_size, page_index, and include_volumes; baseline 3 applies. The description's mention of volumes loosely maps to include_volumes but adds no syntax, defaults, or format 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?

States a specific verb (读取) and resource (某本书的章节列表), plus the accompanying volume list and the returned fields (标题/字数/状态). It is distinguishable from list_books_qimao (books) and list_chapters-adjacent siblings, though it never names an alternative 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?

Gives clear usage context – 复核发布结果与避免重号 (verifying publish results and avoiding duplicate numbering) – which tells the agent when this tool is the right choice. No explicit when-not or named alternative, 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.

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 add one useful behavioral trait — 不联网 (no network/offline needed), which contrasts with the login/cookie siblings — but says nothing about output format, pagination, or size. Adequate disclosure for a read-only list tool, but not rich.

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 front-loaded sentences: the first enumerates the returned content, the second gives usage timing and alternative resources. Efficient, with no padding.

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

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

For a zero-parameter, no-output-schema knowledge tool with no annotations, the description covers content, offline behavior, when to use it, and where to find deeper material. Return format/size is unspecified, but the tool's nature makes that 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?

Zero parameters, so there is no parameter semantics to document; the description does not need to compensate. Baseline 4 applies for a no-parameter tool.

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 (列出/list) plus the resource (主流网文赛道) and enumerates exactly what content is returned: 爽点机制、开篇要求、节奏、避坑清单、建议单章字数. This is unmistakably a knowledge-base read tool, clearly distinct from the CRUD-oriented siblings like list_books_qimao and list_chapters_qimao.

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 clear usage context: '写新书/定赛道前先看它' tells the agent when to call it (before writing a new book or choosing a track), and points to qimao://genres and qimao://golden-three-chapters for the fuller methodology. No explicit when-not condition, but the trigger 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 usefully discloses read-only HTTP and cursor-based pagination, but omits authentication requirements (implied by siblings login_qimao/set_qimao_cookies), rate limits, and error behavior.

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

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

Two sentences, front-loaded with purpose and followed by read-only status and pagination mechanics. Every clause is relevant and there is no wasted text.

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-only list tool, the description covers purpose, returned fields, read-only nature, and pagination, which compensates for the absence of an output schema. Authentication context is missing but is likely handled by sibling login 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 baseline is 3. The description's explanation of cursor pagination ('把返回里的 next_id 再传回来取下一页') largely repeats what the schema already documents for next_id, adding no new syntax or constraints.

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 enumerates returned fields, clearly scoping it to the Qimao author backend. It implicitly distinguishes itself from get_short_story_qimao (singular detail) and list_books_qimao (books) through the resource name, but does not name any 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?

Usage is implied by the resource name: use this to list short stories. Pagination instructions explain how to page, but the description never states when to choose this over list_books_qimao or get_short_story_qimao, nor any preconditions such as needing to be logged in.

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 well: it discloses that a real browser window opens, that the human performs the verification, that the service only polls login state and persists cookies, and that credentials are never handled. It omits failure/timeout behavior and whether saved cookies persist across later calls.

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 tightly packed sentences with no filler; the mechanism and the credential-safety guarantee are both front-loaded and each clause earns its place.

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

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

For a single-parameter tool with no output schema and no annotations, the description covers the interaction model and security posture adequately. It could say more about what happens when the timeout expires or what the tool returns on success/failure.

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?

Only one parameter (timeout_seconds) and schema description coverage is 100%, so the schema fully documents it. The description adds nothing about the timeout semantics, 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?

States a specific verb and resource (login to the Qimao author backend) and explains the mechanism: a real browser window where the user completes QR/SMS verification. This implicitly separates it from set_qimao_cookies, but no sibling is named 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?

Usage is only implied – the agent can infer this is the tool to call when credentials/cookies are needed, but the description never says when to prefer it over set_qimao_cookies or what to do on timeout. No explicit when/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?

With no annotations, the description carries the full behavioral burden and does it well: it warns that the editor may auto-save as you type, that confirm=false only opens the page to read state and screenshot without filling, and that confirm=true actually submits. The 3000–100000 word soft-warning behavior is also disclosed. Missing only auth requirements and reversibility of a published submission.

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-loaded with the purpose, then the two modes, then the critical confirm/auto-save warning. Dense but every clause carries information. The warning emoji and bold bolding aid scanning; slightly cramped as a single dense block.

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 8-parameter, zero-annotation, no-output-schema mutation tool, the description covers purpose, mode selection, parameter interplay, and the most important behavioral risks. It could say more about what a successful publish returns or how failures surface, but it is adequate for correct 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 75%, so many parameters are already documented. The description adds value beyond the schema by stating the mutual exclusivity (book_id vs title), the three-way content source (content/file_path/article_id), and the default value of confirm. It leaves the remaining bare parameters (headless, and the sparse file_path/article_id descriptions) unelaborated.

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 (发布/publish) and resource (短篇), and precisely describes the two operating modes: publish an existing work via book_id or create-and-publish via title(+content). It is clearly understandable without opening the schema. It does not, however, differentiate itself from the sibling create_short_story_qimao, which overlaps in the 'create' branch.

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 clear conditional guidance for selecting a path (book_id for an existing work, title+content for a new one) and explains the confirm gate semantics (false = read-only, true = fill and submit). It stops short of naming alternatives or stating explicit when-not conditions, e.g. how it relates to create_short_story_qimao or save_article.

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 the storage target (data/articles.json), the return value (article_id), the upsert behavior, and crucially that updates only overwrite explicitly passed fields. It omits error/failure behavior and what defaults apply to unset fields on 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?

Dense but front-loaded: the storage action and return value come first, followed by create/update rules and kind/content notes. Every clause carries information, though the single run-on paragraph with multiple parentheticals is slightly heavy.

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 9-parameter upsert tool with no annotations and no output schema, the description covers the essential behaviors and the return value. Minor gaps remain around required fields for creation and failure handling, but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents kind, article_id semantics, and content/file_path exclusivity. The description mostly restates these, adding only the partial-overwrite nuance rather than new per-parameter meaning.

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

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

States a specific verb+resource (把正文入库 to data/articles.json) and clearly explains the dual create/update nature based on whether article_id is passed. It doesn't name sibling tools (e.g. the remote add_chapter_qimao/update_chapter_qimao or get_article), so sibling differentiation is only implicit via the local-file mention.

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 concrete routing conditions: omit article_id to create, pass it to update; kind=chapter vs kind=short; content vs file_path. It stops short of stating when NOT to use this tool or which sibling to reach for when publishing remotely.

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 the idempotent 'skip already-selected' behavior and the dry-run-by-default confirm semantics (opens page, fills form, screenshots, no submit vs. actual save). It omits auth/session prerequisites, which is a minor gap given the sibling login/set_cookies tools.

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 purpose and semantics, then the confirm-mode behavior, in a tight multi-clause block. Every clause earns its place; the parenthetical on reuse is slightly tangential but informative rather than wasteful.

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, the description covers the key behavioral facts an agent needs (dry-run default, commit flag, idempotent tag selection). It doesn't mention return/response behavior or auth requirements, leaving minor gaps.

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 baseline is 3, but the description adds real value beyond the schema: it explains that confirm=false is a dry-run and confirm=true commits, and that tags/category are 'ensure selected' rather than replace. This meaningfully augments the terse schema descriptions.

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

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

States a specific verb+resource ('为已有作品设置分类/标签') and clarifies the exact semantic as 'ensure these tags are selected'. It names a sibling (update_book_info_qimao) whose page flow it reuses, giving partial differentiation, though it doesn't fully spell out why an agent would pick this over that 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?

Explicitly defines the two usage modes: confirm=false opens the page and fills the form without submitting, confirm=true saves. The 'ensure selected / skip already-selected' semantics clarifies expected usage. It stops short of an explicit when-to-use-vs-alternative statement against update_book_info_qimao.

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

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

With no annotations, the description carries the full burden. It usefully discloses the accepted input format (array or {cookies:[...]}) and source formats (browser-plugin exports), but says nothing about persistence, whether existing cookies are overwritten, or authentication/security implications for a credential-setting 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, front-loaded with the action and source, followed by the format constraint. No filler; could arguably state the login_qimao fallback relationship more explicitly, but it is tight.

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 2-parameter, fully-covered-schema tool with no output schema, the description covers input formats adequately. It is incomplete on behavioral aspects a cookie tool needs (persistence, overwrite semantics, when to prefer it over login_qimao).

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 baseline is 3, but the description adds genuine meaning beyond the schema by specifying the required cookies format (array or {cookies:[...]}), which the schema's plain 'JSON text' does not convey.

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 (import Qimao cookies) plus the accepted sources (text or file path), which is clear. The title's '备用' (backup) hints at the sibling relationship with login_qimao, but the description body itself doesn't name that alternative, so it falls short of full sibling differentiation.

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?

'手动导入' (manual import) and the title's '备用' (backup) imply this is a fallback for when login_qimao is unavailable, so usage is implied. However, no explicit condition, prerequisite, or named alternative appears in the description text.

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 mostly succeeds: it discloses partial-update semantics ('只覆盖显式传入的字段'), the surprising default that confirm=false performs a read-only screenshot preview, and side effects (re-review / exposure impact on name/summary changes). It omits auth/permission requirements and error behavior.

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

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

Front-loads the action and affected fields, then the critical confirm caveat, then the risk notice. Dense but every sentence earns its place; minor cost from the emoji/bolding emphasis.

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 important behavioral ground: partial update, preview-vs-commit, and risky fields. Missing auth requirements and failure modes keep it from full completeness.

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

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

Schema coverage is already 100%, so the schema defines every field (不给＝不改). The description adds value beyond the schema by explaining the confirm gate and the re-review consequence of the name/abstract fields, going past the baseline 3 for fully-covered schemas.

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 (已有作品的名称/简介/主角名/分类), enumerating exactly which fields are in scope. This clearly differentiates it from sibling writers such as create_book_qimao, update_novel, and set_book_tags.

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 clear context for use: modifying an existing work via the 作品信息页, and explains the confirm=false vs confirm=true branch. It does not explicitly name or exclude the sibling update_novel, so there is a residual ambiguity that keeps it below a 5.

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 does disclose two non-obvious traits: the editor auto-saves as it types, and the default mode performs no filling at all (read + screenshot only). It does not describe permission/auth requirements, failure modes, or what the call returns, and the screenshot/preview output format is only alluded to.

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-loaded with the action and scoping, then the critical confirm rule; the parenthetical asides are short and each carries information. Slightly dense with two levels of parenthetical nesting, but no filler sentences.

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 10-parameter, no-output-schema tool, the description covers the highest-risk aspects (auto-save, default read-only preview, body source options, chapter_id origin). It leaves headless, scheduled_time, chapter_number and the shape of the read-mode result to the schema, which documents them, so the gap is minor.

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 confirm, book_id, chapter_id and the content/file_path/article_id trio is already documented in the schema. The description restates the three-way body-source choice and the confirm gate but adds no format, precedence, or syntax detail beyond the schema (article_id 优先 is already in 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?

States a specific verb + resource (修改已有章节的标题/正文) and the mechanism used (走章节编辑器，按 chapter_id 定位), which separates it from add_chapter_qimao and delete_chapter_qimao at a glance. An agent can identify this as the edit-existing-chapter tool 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?

Gives a concrete operating rule: confirm=false only opens the page, reads current state and takes a screenshot; confirm=true actually fills and submits. That is real when-to-use guidance for a risky mutation. It stops short of naming alternatives (e.g. update_novel for body text, add_chapter_qimao for new chapters) or prerequisites like required login.

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 does real work: it discloses patch semantics (unsupplied fields keep their original value), the *_file indirection for long text, and that the operation is purely local with no backend side effects. It omits what happens if novel_id does not exist, and whether qimao_book_id binding has any remote consequence.

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 that front-load the resource and its locality constraint, then the merge semantics, then the file convention. The enumerated field list is long but does useful disambiguation work; only the trailing resource pointer is arguably optional.

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 24-parameter mutation tool with no annotations and no output schema, the description covers the essential unknowns: locality, merge semantics, and long-text handling via files. It does not describe the returned shape or error behavior on a missing/unknown novel_id.

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 24 parameters, putting this at the baseline 3. The description adds the partial-update rule and the *_file convention, plus a pointer to list_genres for genre keys, but most of it restates what the schema already says field by field.

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 (修改/update) and resource (本地小说登记 data/novels.json), then enumerates the exact field families it touches and explicitly marks the boundary: 纯本地，不改动七猫后台. This cleanly separates it from the sibling update_book_info_qimao, which an agent could otherwise confuse it 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?

Provides the key usage context: this edits local metadata and creation settings, does not touch the Qimao backend, and reading is done via the resource qimao://novels. It also states the partial-update contract (只覆盖显式传入的字段). However, it never names a sibling alternative or a when-not-to-use case, leaving the agent to infer the split against update_book_info_qimao.

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