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

With no annotations, the description carries the full burden, and it does well: it discloses the multi-step pipeline, the confirm=false dry-run default (a real safety gate against accidental publishing), a typo re-confirmation step, and a final interface review. It omits auth/login requirements and rate/error behavior, which keeps it below 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?

Purpose is front-loaded and the text is dense with no filler, packing the workflow, body sources, scheduling, and default behavior into one paragraph. The arrow-chain notation is slightly cryptic and could be tightened, but nothing 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 an 11-parameter, no-annotation, no-output-schema multi-step publishing tool, the description covers the workflow, the dry-run gate, body sources, and scheduling well. It still leaves auth prerequisites and post-submission return/error behavior unexplained, which are notable gaps given the sibling login_tomato exists.

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 all 11 parameters including the three body-source options and the confirm/default behaviors are already documented in the schema. The description restates content/file_path/article_id and scheduled_time support but adds little meaning 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?

The description states a specific verb and resource: uploading one chapter to a specified book on the 番茄 platform, with the full submission flow spelled out. It is clearly distinguishable in intent from list_chapters_tomato or batch_publish_chapters, but it never explicitly names a sibling to route against, so it falls short of the 5 bar.

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 implies usage through the workflow and the critical note that confirm=false only fills the form without submitting, which tells the agent how to dry-run. However, it gives no explicit when-to-use vs batch_publish_chapters or publish_short_story_tomato, and no prerequisite (e.g. login) guidance, so usage is implied rather than directed.

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 so well: it discloses rate limiting, sequential ordering, fault tolerance (a single failure does not abort the batch), per-chapter results, and the dry-run behavior that avoids leaving stray drafts. It omits permission/auth requirements and the semantics of mode flags like use_ai and detection.

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 the core batch behavior front-loaded and the dry-run caveat following. Every clause carries information; slightly dense but efficient.

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 tool with no annotations and no output schema, the description covers the primary workflow and failure handling but leaves several mode parameters (use_ai, detection, headless) unexplained and says nothing about required authentication or setup prerequisites.

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 78% (near the 80% baseline), so the schema documents most parameters. The description clarifies confirm's dry-run behavior and the chapter ordering, but adds no meaning for limit, use_ai, detection, or headless, which are undocumented or only minimally described in the schema.

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

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

The description states a specific verb and resource: selecting pending-publish chapters from the local manuscript library and uploading them in chapter-number order. It is unambiguous what the tool does, though it never names a sibling (e.g. add_chapter_tomato) to differentiate the batch vs single path 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 through the confirm=false dry-run note, which tells the agent how to preview safely, but there is no explicit statement of when to prefer this over add_chapter_tomato or the other publish siblings. Nothing is misleading, but the when-not guidance is left to inference.

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

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

With no annotations the description carries the full burden, and it delivers the most important trait: the write is gated behind confirm=true, defaulting to a safe dry-run preview. It also enumerates tag caps, which is real behavioral detail. It omits auth/prerequisite state, failure modes, and rate limits.

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 required fields, then tag caps, then the confirm gating. Every clause carries an actionable constraint (lengths, caps, mode) with no filler.

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

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

For a 10-parameter mutation tool with no annotations and no output schema, the description covers the core requirements and the critical confirm gate well. It leaves headless, register_local, and reading_tags unexplained and says nothing about the return shape or post-submission behavior.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine value beyond it by giving the numeric tag ceilings (情节≤4/情感≤2/人设≤4/世界观≤1) that the schema only gestures at as '各有上限'. It restates the required fields and length limits rather than adding new meaning for title/gender/abstract.

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 with scope: '在番茄作者后台真实建书' (actually create a book on the Tomato author backend). The '真实' qualifier and '建书' distinguish it from siblings like create_short_story_tomato and add_chapter_tomato without needing 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?

Explicitly defines the two operating modes: '默认 confirm=false 只做预检与预览，不建书；confirm=true 才真正提交' — a clear when-to-use-each-condition rule. It stops short of naming sibling alternatives or prerequisites (e.g. login_tomato must run first), so 4 rather than 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?

无 annotation，描述提供了重要行为细节：自动创建草稿 item 并返回 item_id、字数限制、正文来源的多选一机制，以及 confirm 参数对是否持久化的控制。但未说明失败情形、权限要求或网络副作用等。

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?

对于无 annotation、无输出模式的创建类工具，描述覆盖了核心操作、字数约束、正文指定方式及 confirm 语义，足以指导正确调用。但缺少错误处理、认证需求等边界情况说明。

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 提供。描述补充了正文三选一的优先级（content/file_path/article_id）以及 confirm 的行为影响，但未解释其他参数如 headless、use_ai 等的具体含义，仅重复 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?

描述明确说明该工具新建短故事，并可选保存草稿，动词+资源清晰。同时通过提及自动生成草稿 item 和返回 item_id，将其与 create_novel_tomato 等兄弟工具区分开来。

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?

描述了何时实际保存草稿（confirm=true）与仅填表不保存（默认 confirm=false），但未明确提及何时应选择此工具而非其他创建工具，也未说明使用该工具的前置条件（如登录要求）。

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 two key traits: the operation is local-only and does not touch the Tomato backend, and the default confirm=false performs a preview rather than an actual delete. It stops short of stating reversibility or what happens after a real delete.

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 compact sentence that front-loads the scope constraint and the safe-default behavior, with no filler.

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

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

For a two-parameter delete tool with no annotations and no output schema, the description supplies the two things an agent most needs: scope (local-only) and the dry-run default. Marginal gaps remain around irreversibility and return behavior, but these are 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 coverage is 100% and both parameters are already documented in the schema, including confirm's default-false meaning. The description restates the preview behavior but adds no syntax or format detail beyond the schema, 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 (删除/delete) and resource (本地文稿库条目/local article library entry), and explicitly scopes it as local-only, which distinguishes it from the remote sibling delete_short_story_tomato. An agent can identify the target from the description alone.

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 clause '不影响番茄后台' signals the condition under which this tool is appropriate (local-only deletion, not backend mutation), which helps route against backend-facing siblings. It does not, however, name an alternative tool or state when-not to use it 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the destructive nature and the two-phase confirm=false preview vs confirm=true real-deletion behavior, which is important safety context. It does not mention permissions or irreversibility details, but the core destructive semantics are 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 tightly packed sentences with zero waste. The destructive flag and confirm behavior are front-loaded and easy to parse.

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

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

For a low-complexity deletion tool with a fully described two-parameter schema and no output schema, the description covers the key behavior an agent needs. It could add one clause about alternatives or permission requirements, but no critical information 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 adds meaningful semantics for confirm by explaining that false only previews and true performs the deletion. This goes beyond the schema's wording that confirm simply means 'whether to truly delete, default false'.

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 (指定短故事或草稿), clearly distinguishing this tool from article-deletion and other siblings. The core action 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?

The description implies usage for deleting short stories or drafts, and explains the confirm preview/delete behavior. However, it does not explicitly say when to choose this tool over alternatives such as delete_article, so usage guidance remains implied rather than explicit.

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?

With no annotations, the description carries the full burden, and it does disclose a genuinely non-obvious side effect: verify_login=true actually launches a headless browser to validate the session, which signals real cost and external interaction. It also tells the agent the tool returns fix-it guidance rather than raw status. It does not describe behavior on partial failure or the exact return shape.

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 zero filler; the set of checks is front-loaded and the one behavioral caveat is appended where an agent will see it. Nothing could be cut without losing 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 a one-parameter, no-output-schema diagnostic tool with no annotations, the description covers what is checked, what it returns, and the cost caveat of the verify flag. It is nearly sufficient, with only failure-mode behavior 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 description coverage is 100%, so the single parameter is already documented including its default. The description restates verify_login's effect, adding a little emphasis ('真开一次无头浏览器') but no new syntax or format semantics. Baseline 3 applies when 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?

The description names three specific checks (cookies / browser driver / backend reachability) and states it returns remediation guidance, which is far more specific than the bare name 'get_publish_status' would suggest and prevents confusing it with an actual publish-report tool. It stops short of explicitly contrasting itself with siblings like batch_publish_chapters or set_tomato_cookies.

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 checks and remediation hints clearly position this as a preflight diagnostic before publishing, but the description never says 'run this before X' or when-not to use it. No alternative tool is named or ruled 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 does usefully disclose which fields are returned (title, word count, category, signing status, modifiability) since there is no output schema, and notes the endpoint tag (edit/v1). However, it says nothing about auth requirements, error behavior, or whether a missing item_id/story returns an error.

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 compact sentence with the resource and returned fields front-loaded and no filler. The trailing '(edit/v1)' is slightly cryptic but does not bloat the 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 one-parameter read tool with no output schema, enumerating the returned fields is the right compensation and makes the definition usable as-is. The main residual gap is the absence of any auth or usage context that siblings imply.

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 there is a single required item_id that the schema already documents. The description adds no extra syntax, format, or sourcing 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?

States a specific verb (读取) and resource (某条短故事), and enumerates the fields it retrieves (title, body word count, category, signing status, modifiable). The singular '某条' plus item_id distinguishes it from list_short_stories_tomato, but the description never names that sibling to make the contrast explicit.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g. needing login_tomato/set_tomato_cookies first), and no routing against siblings like list_short_stories_tomato or get_publish_status. The agent must infer that this fetches one story by id.

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 what is read (local library/tasks/registrations, an environment self-check, optionally the Tomato backend), which is meaningful. It omits whether the backend read requires an authenticated session (login_tomato / set_tomato_cookies exist as siblings), and gives no side-effect or rate-limit context, leaving a notable gap for a network-touching 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 environment/aggregation scope front-loaded and the conditional remote clause at the end. No filler, though the semicolon-linked clauses compress two distinct behaviors into one line.

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

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

There is no output schema and no annotations, so the description must carry the load. It names the data sources but not what the returned statistics contain or how the self-check result is presented, which is a gap for a multi-source aggregate tool. Adequate but not complete.

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

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

Schema description coverage is 100%, so both remote and headless are already documented in the schema. The description reinforces that remote=true triggers an extra backend read, but adds no syntax or format detail beyond the schema, and never mentions headless. Baseline 3 is correct.

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

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

States a specific aggregate verb and enumerates the resources it summarizes: 本地文稿库/任务/登记 plus 环境自检, and the additional backend read when remote=true. An agent can tell it is a roll-up/stats tool rather than a list or create tool. It stops short of explicitly naming a sibling it replaces, so it falls just below 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?

It gives one conditional: remote=true additionally reads the 番茄 backend lists, implying the default local-only mode. However there is no explicit when-to-use-vs-alternatives guidance against siblings like get_publish_status or list_novels_tomato, so usage is only implied.

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

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 carries the full burden. '读取' implies a read-only operation and the listed return fields (title/word count/status) add useful context, but it omits pagination behavior, auth/session prerequisites despite login_tomato existing, and ordering. Decent but incomplete for a tool with zero annotation coverage.

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 that identifies the resource, the scope, the returned data, and the purpose with no filler. 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?

For a simple one-parameter read tool, the description covers resource, scope, return fields, and purpose. Missing only pagination/auth details, which is acceptable given the tool's low complexity and absent output schema.

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

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

Schema description coverage is 100% with a single required book_id already documented in the schema. The description adds nothing about parameter format or semantics 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?

States a specific verb+resource in a scoped way ('读取番茄后台某本书的章节列表') and enumerates the returned fields (标题/字数/状态). An agent can distinguish it from sibling mutation tools like add_chapter_tomato and batch_publish_chapters without opening either 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 clause '用于复核发布结果与避免重号' gives implied usage context — post-publish verification and duplicate-number avoidance — but names no alternatives (e.g. get_publish_status) and states no when-not conditions. 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. It discloses that the tool reads the remote backend and can optionally sync results into a local registry, but it omits authentication requirements, sync overwrite/merge behavior, and error conditions.

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

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

The description is two compact sentences with no filler. It front-loads the core read action and follows with the optional sync side effect.

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

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

For a one-parameter tool with no output schema, the description supplies the main return concept, real book_id, and the optional side effect. It could be more complete by stating the login/cookie prerequisite, but the essential call context is present.

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

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

Schema coverage is 100%, so the boolean parameter is already documented. The description adds useful intent beyond the schema by explaining that syncing is for batch upload, though it does not add format or edge-case semantics.

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

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

The description states a specific verb and resource: reading the author backend's real novel list. It also clarifies the key output, real book_id, and distinguishes this from a local registry, so an agent can tell what the tool returns.

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: verifying/backfilling and optionally syncing for batch upload. It does not explicitly name when not to use it or point to an alternative sibling, so it stops short of full routing guidance.

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

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 says '读取' (read), which implies a safe read-only operation, and maps status=draft to the drafts box, but it does not disclose pagination behavior, return format, authorization requirements, or rate limits.

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 with no wasted words. The main purpose is front-loaded before the conditional status behavior, making it easy to scan.

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, no output schema, and 67% of parameters undocumented in the schema, the description is too thin. It does not explain pagination parameters or expected return structure, which an agent needs for a list tool with three parameters.

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

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

Schema description coverage is only 33%, with status documented but page_count and page_index left undescribed. The description only repeats the status=draft behavior already stated in the schema, adding no meaning for the undocumented pagination parameters.

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

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

The description states a clear verb-resource pair: reading the author's backend short story list. It distinguishes the tool from sibling list tools by naming 'short stories' rather than novels, chapters, or articles, but it does not explicitly call out alternatives or exclusions.

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 one conditional use case: when status=draft, it reads the drafts box. There is no explicit guidance on when to prefer this over other list tools or what happens when status is 'all' beyond the schema default.

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 disclosure burden and does well: it reveals the human-in-the-loop requirement (user must interact in a window), the polling-and-cookie-persistence behavior, and the absence of credential handling. It omits failure/timeout behavior and whether it overwrites existing cookies, which matters for a login that writes auth state.

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

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

A single tightly packed sentence that front-loads the key mechanical fact (a real browser window opens) and the interaction model. No filler; every clause (scan/captcha, polling, cookie saving, no passwords) carries distinct 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 a one-parameter login tool with no output schema and no annotations, the description covers the essential mechanics an agent must know before invoking it. What remains missing is the post-call outcome (success/timeout handling) and the interaction with existing cookies, but these are minor for this tool's complexity.

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

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

Schema description coverage is 100% and the single parameter timeout_seconds is fully documented in the schema, so the baseline of 3 applies. The description adds nothing about the timeout parameter or its default, but the schema already does the work.

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 (login) and resource (Tomato author backend) and uniquely characterizes the semi-automatic mechanism (opens a real browser, user scans QR/passes captcha, service polls and saves cookies). It is unambiguous, but it never names its closest sibling set_tomato_cookies, leaving the boundary between the two login paths 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?

The description implies the usage context (a browser-driven login flow) and clarifies that no account password is involved, but it offers no explicit when-to-use guidance, prerequisites, or comparison to set_tomato_cookies. The agent must infer that this is the path to take when cookies are absent.

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, and it discloses real behavioral traits: the confirm gate, the draft→next→publish pipeline, the real-name/face verification interrupt that halts and hands off to a human, and the 6000–80000 word-count constraint. It does not mention auth/login prerequisites despite the login_tomato sibling, leaving a small 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?

Five compact clauses, front-loaded with the action and then the mode/confirm/verification/constraint details in priority order. No filler sentences; every clause carries operational 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 a 12-parameter, no-annotation, no-output-schema mutation tool, the description covers the core operation thoroughly: modes, confirmation gating, pipeline stages, failure/interrupt behavior, and validation bounds. Remaining gaps are the auxiliary parameters (categories, cover_path, use_ai) and what a successful call returns.

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

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

Schema coverage is 67%, so the description must add meaning, and it does: the item_id-alternates-with-title(+content) routing rule and the confirm=false/true semantics are behavioral routing that the schema alone does not state. It leaves use_ai, file_path, article_id, cover_path, and divided_chapters unexplained by either source.

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 the two supported operation modes: publishing an existing work via item_id versus creating-and-publishing via title(+content). This separates it cleanly from siblings like create_short_story_tomato and save_article.

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 for the two entry paths (item_id vs title+content) and the confirm=false preview versus confirm=true publish distinction, which is exactly the when-to-use guidance an agent needs. It stops short of naming which sibling to use for adjacent jobs (e.g. create_short_story_tomato for drafts), so it is clear context without explicit alternatives.

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

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

With no annotations, the description carries the full burden. It usefully discloses the storage location and the article_id return, plus the content/file_path alternative, but says nothing about overwrite/duplicate behavior, permissions, or whether saving is idempotent — the main risks for a persistence 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?

Three short, front-loaded sentences with no filler: destination and return value come first, then the kind branching and the content source. Dense but 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?

For a 9-parameter, no-annotation, no-output-schema tool, it covers the essentials — where data lands, what comes back, and the key conditional parameters. It leaves the optional tomato_* linkage fields and conflict handling unaddressed, which is a modest gap rather than a blocking one.

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

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

Schema coverage is 100%, so the baseline is 3, and the description goes beyond the per-field text by encoding the conditional relationships: kind=chapter pairs with novel_id/chapter_number, kind=short is for short stories, and content vs file_path are the two ways to supply 正文.

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 (把正文入库), names the concrete store (data/articles.json), and names the return value (article_id). The local-file target implicitly separates it from the Tomato-publishing siblings (add_chapter_tomato, create_short_story_tomato), though 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?

It gives a rationale (避免把长文本反复塞进工具参数) and splits usage by kind, which hints at when each variant applies. But it never states when to use this local save versus the publish-oriented siblings, nor any prerequisites such as an existing novel_id.

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 non-obvious internals: the upload goes through the edit-page entry and the page performs the cover/v0 signing itself, plus the two-stage upload-then-save semantics driven by confirm. It omits auth/login prerequisites and failure behavior, keeping it short of 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?

Purpose is front-loaded in the first clause, and the parenthetical plus one short sentence about confirm carry real information without padding. Nothing is wasted, though the parenthetical interrupts the main clause slightly.

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 mutation with no annotations and no output schema, the description covers the upload/persist mechanism adequately but leaves the headless flag unexplained and says nothing about authentication, permissions, or what success/failure looks like.

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 baseline is 3. The description repeats the confirm default that the schema already documents and adds nothing about headless, the one undocumented parameter, nor about cover_path format beyond "本地封面图片路径".

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 (upload a local cover image) applied to a specific resource (an existing short story), and the parenthetical explains the mechanism used (the edit page's file upload entry). This clearly separates it from siblings like create_short_story_tomato, delete_short_story_tomato, and publish_short_story_tomato.

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 implies the story must already exist ("为已有短故事"), which is a useful precondition, and notes the default confirm=false behavior. However, it never names an alternative (e.g. setting a cover at creation time via create_short_story_tomato) or states when this tool should not be used, so usage is only implied.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the accepted input formats but says nothing about side effects such as whether imported cookies overwrite existing ones, whether authentication is required first, or how the operation affects session state. For a write-style cookie import tool, that is a significant 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?

The description is two concise sentences with no redundant or filler content. The core action is front-loaded, and the format requirement follows immediately, making it easy to scan and act on.

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 tool with no output schema and no annotations, the description covers input format and source adequately. It does not explain when to prefer this over login_tomato or what happens after import, leaving behavioral context incomplete. An agent can invoke it, but with some uncertainty about side effects.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that cookies may be either a JSON array or a {cookies:[...]} object, and that browser-plugin exports are acceptable. It also reinforces the text-or-file-path choice, which is useful for constructing the call correctly.

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: manually importing cookies from text or a file path. It also clarifies the expected format, so the agent knows exactly what the tool does. However, it does not explicitly name a sibling (e.g., login_tomato) to differentiate this tool from alternatives, keeping it 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?

The word '手动' (manually) implies this is an alternative to automatic login, but the description never states when to use this instead of login_tomato or other sibling tools. There is no explicit condition or exclusion. Usage is only implied through the manual/backup framing.

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