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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is known. The description adds real behavioral context beyond them: the request is persisted, only subsequent groups stop immediately, and critically '返回canceling不代表已停止' — a returned 'canceling' status is not proof of actual stoppage. That caveat is exactly the kind of async nuance annotations cannot convey.

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 ordered well: action and effect first, parameter semantics second, then the return-value caveat last. Every clause carries information; no filler or restatement of the tool name.

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, asynchronous mutation with no output schema, the description covers what is affected, that the request is persisted rather than instantaneous, and how to interpret the immediate return. Minor gaps remain: no mention of permissions, of whether a cancelled batch can be resumed via tnd_retry_batch, or of how to confirm the batch actually stopped (presumably tnd_get_batch_status).

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 only 50%: batch_id is documented in the schema, while cancel_current has no schema description. The description compensates fully by explaining its default (false) and the distinct behavior of each value. It does not explain the batch_id-must-match constraint in prose, but the schema already covers that.

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: '持久化请求取消指定批次' (persistently request cancellation of the specified batch), plus the scope of effect ('立即停止后续分组'). This clearly distinguishes it from read-oriented siblings such as tnd_get_batch_status and the counterpart tnd_retry_batch, though it never names those siblings 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?

Guidance is limited to the cancel_current choice (false = let the current task finish naturally, true = worker sends a cancel signal after verifying identity). That is useful, but it is essentially parameter-level guidance. Nothing says when to prefer this tool over checking status first with tnd_get_batch_status or when to follow up with tnd_retry_batch.

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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description reinforces the offline nature and adds that no content is returned, which is useful, but says nothing about what happens on invalid chapters, error reporting, or whether missing items count as failures.

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 core scope first and the three exclusions tight behind it, then the item count cap. No filler and no 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?

With no output schema, the description should indicate what a validation check returns (per-item validity flags, error list, counts). It only tells the agent what is not returned ('不返回正文'), leaving the actual result shape unspecified for a tool whose entire purpose is producing a validation verdict.

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 must carry parameter meaning, yet it only restates '最多50个item_ids' — a limit already encoded as maxItems: 50 in the schema. book_id is never explained (book identity format, whether it must match the local library), and the string-id format for item_ids 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?

The description states a specific verb+resource combination (check whether local chapter body content is valid) and immediately delimits it against the read/download siblings via '不联网、不下载、不返回正文'. It stops short of 5 because it never defines what 'valid' actually means, so the agent knows the scope but not the exact check being performed.

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?

'仅检查本地章节正文' plus the three negations effectively communicate when this tool applies (local-only validation, no fetching). However, no sibling alternative is named, so an agent weighing this against tnd_get_chapters or tnd_list_downloaded_chapters gets no explicit routing signal, and no prerequisites are 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 provided, the description carries the full behavioral burden. It discloses that this is a read operation and explains the default-current-batch behavior, but it does not describe permissions, error behavior, or what the returned status contains.

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

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

The description is a single front-loaded sentence with no redundant wording. The default behavior is included efficiently after the main purpose.

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 this is adequate to invoke correctly, especially because the schema documents the parameter fully. However, without an output schema, the description does not explain what status information is returned or how errors are represented.

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 parameter is already documented. The description adds meaningful semantics beyond the schema by stating that when batch_id is omitted, the current batch is returned.

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 discrete download batch status. It is distinguishable from general status or job tools by the word 'batch', but it does not explicitly name siblings like tnd_get_status or tnd_get_jobs.

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 purpose of reading batch status, and the description notes that omitting batch_id returns the current batch. However, it does not say when to use this instead of tnd_get_status, tnd_get_jobs, or tnd_get_book_status.

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 does disclose two useful traits: the data is local (本地) and the response excludes full chapter text. However, it never says what the summary contains, whether a download prerequisite must be satisfied, or how it behaves for a book that was never downloaded.

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

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

A single sentence with two purposeful clauses: the primary action is front-loaded and the exclusion clause follows immediately. Nothing is redundant and no words are 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?

The tool is simple (one required parameter, no nested objects, no output schema), so little explanation is needed. Still, with no output schema the vague term '本地摘要信息' leaves the agent unsure what fields come back, and the not-downloaded case is unaddressed.

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

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

Schema description coverage is 100% with a single required book_id already documented as a numeric book ID. The description's phrase '某本已下载书籍' only reinforces that the ID must refer to a downloaded book, adding marginal meaning beyond the schema. 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 states a concrete verb+resource: read the local summary info of a downloaded book. It also draws one boundary by saying it does not return full chapter body text, which separates it from the read_downloaded_chapter* siblings. It does not distinguish itself from near-neighbours like tnd_get_status, tnd_check_chapters or tnd_preview_book, so sibling differentiation is only partial.

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

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

Usage is implied rather than stated: an agent can infer this is for inspecting an already-downloaded book's metadata without pulling chapter content, and the 'does not return full chapter body' clause implicitly routes content reads to the read_downloaded_chapter* tools. There is no explicit when-to-use/when-not-to-use statement and no mention of what happens if the book is not downloaded.

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 already flag readOnlyHint=false and openWorldHint=true, and the description usefully explains why: with download_missing it may create or reuse a download batch, and it returns immediately rather than waiting. That is real added context. It still omits what happens to chapters that are missing (are they absent from the response or listed as missing IDs?), error/auth behavior, and any side effect of reusing an existing batch.

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

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

A single tight statement that front-loads the most important rule (local content first) before the conditional download behavior. It is dense and clause-heavy but every clause carries information; 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 5-parameter, non-read-only, open-world tool with no output schema, the description does sketch the return shape (existing 正文, missing IDs, batch_id) and the non-blocking contract. It leaves truncation semantics (max_total_chars / max_chars_per_chapter) and failure behavior unexplained, which matters given the mutation-capable path.

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 carries the full burden, yet it only explains download_missing and echoes the 20-chapter cap that is already encoded as maxItems:20. book_id, max_total_chars, and max_chars_per_chapter (default 0, meaning unclear) get no explanation at all, so a third of the parameters remain opaque.

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 (read chapter 正文 for a set of item_ids), plus the key differentiator that it never blocks waiting for downloads. It does not name any sibling (e.g. tnd_read_downloaded_chapters, tnd_check_chapters, tnd_start_chapter_download) to sharpen the boundary, but the local-first/non-blocking framing is clear enough to distinguish it.

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 states the conditional rule for the risky path: only create or reuse a batch when download_missing:true, otherwise read local content only. That implies the agent should follow up with batch-status/polling tools rather than expect the content inline, but no alternative tool is named and no explicit when-not-to-use guidance is given.

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

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

With no annotations, the description carries the full burden; it does disclose a genuine behavioral trait beyond the schema — that timestamps come back in both UTC and Beijing time — which helps an agent interpret results. However, it omits pagination behavior (limit defaults to 100, capped at 500), whether the result is a complete or paged list, and any ordering of chapters, all of which matter for a list 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 front-loaded sentence with no filler; the resource and the key return detail lead. The trailing time-zone clause is slightly redundant in phrasing (时间同时返回) but still earns its place by clarifying output format.

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

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

Given a read-only list tool with no output schema and no annotations, the description covers what is returned and in what time format, which is the critical unknown. It falls short on pagination and the optional item_id filter, so an agent cannot tell from the description alone how to page through a large catalog.

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 50%: book_id and item_id are documented, but limit and offset have no descriptions anywhere. The description does not compensate at all — it never mentions pagination, the per-chapter item_id filter, or the maximum page size, so half the parameters remain opaque.

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 (番茄章节目录 + 每章首次发布时间/firstPassTime), and specifies the timestamp format returned. This lets an agent distinguish it from write/download siblings, but it never contrasts itself with the closely related catalog siblings such as tnd_get_chapters, tnd_check_chapters, or tnd_list_downloaded_chapters.

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

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

There is no explicit when-to-use guidance and no exclusions or named alternatives, despite a crowded sibling set of four other chapter-listing tools. An agent must infer from the name alone whether this is the right catalog call versus tnd_get_chapters or tnd_check_chapters.

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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real value beyond them by bounding the data exposure ('不返回密码或Token') and confirming it will not alter configuration, which tells the agent it is safe to call purely for inspection.

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 verb and followed by a semicolon-delimited list of checks, then the negative constraints. Nothing is redundant, though the run-on list format makes it slightly harder to scan than a short structured breakdown would be.

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

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

With no parameters, no output schema and full annotation coverage, the definition covers the checks performed and the safety boundaries. The only gap is that it does not hint at the shape of the returned diagnostic results, which matters somewhat since no output schema exists to describe them.

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 baseline this scores 4; the description correctly describes a no-argument aggregate diagnostic rather than implying any inputs.

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

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

The description names a specific verb (诊断/diagnose) and enumerates the concrete resources checked: connectivity and version, shared-directory read/write permissions, download-path consistency, worker heartbeat and batch status. That is far more specific than a sibling like tnd_get_status or tnd_get_batch_status, though it never explicitly says how it differs from those 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?

Usage is only implied: the enumeration of checks signals a troubleshooting/sanity-check tool to run when downloads misbehave. There is no explicit statement of when to prefer this over tnd_get_status or tnd_get_batch_status, and no prerequisites or exclusions are given.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the bare purpose. It omits ordering (newest first?), whether results are paginated, what fields a record contains, and whether history is local or server-side.

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 short sentence with no wasted words and the core purpose front-loaded. However, the brevity reflects under-specification rather than disciplined conciseness.

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 only half the parameters documented, the description should explain the record shape, ordering, and pagination. As written, an agent cannot predict the response or how to page through large histories.

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 the 'q' parameter is documented in the schema (50% coverage), and the description adds no meaning about matching behavior (substring vs exact, title vs ID) or the practical effect of 'limit'. The description does nothing to compensate for the uncovered parameter.

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 concrete verb+resource ('读取下载历史记录'), so an agent knows it retrieves past download records. It does not distinguish this from adjacent siblings such as tnd_get_updates, tnd_get_library, or tnd_list_downloaded_chapters, leaving overlap ambiguous.

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 exclusions, and no mention of alternatives. With a sibling set containing several history/library/download-listing tools, an agent has no signal for choosing this one over tnd_get_updates or tnd_list_downloaded_chapters.

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 supplied, so the description carries the full disclosure burden. It does not state whether the operation is read-only (implied only by '读取'), what the default time window for '最近' (recent) means, whether results are paginated or truncated, or whether an empty job list is a normal return.

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 short sentence that front-loads the core purpose with no wasted words. It is efficient, though its brevity is partly the reason other dimensions are thin.

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 read tool with no output schema, the description is minimally adequate: it conveys that both active and recently finished jobs are returned. It omits what fields each job entry contains and any notion of ordering or limits, which leaves gaps an agent inspecting results would want filled.

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

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

Schema description coverage is 100%, so both parameters ('all' and 'name') are already documented in the schema. The description adds no additional meaning about how 'all' interacts with the default recent-only scope, 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: '读取当前下载任务和最近完成任务' (read current download tasks and recently completed tasks). This clearly separates the tool from sibling readers like tnd_read_latest_chapter or tnd_get_history, but it never names a sibling to sharpen the distinction, so it falls short of a 5.

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

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

No guidance is given on when to call this tool instead of alternatives. The sibling set includes tnd_wait_job, tnd_get_batch_status, and tnd_get_status, which the agent might reasonably conflate with this one, yet the description offers no routing rules or exclusions.

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 exist, so the description carries the full behavioral burden. It usefully discloses a negative behavior (no chapter text returned), but says nothing about whether the listing is read-only, what side effects a scan has, or what the response looks like. Fully read-only behavior is implied by 列出, not stated.

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 with the subject (listing local files/subdirectories) front-loaded and the exclusion clause appended. Nothing is redundant.

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

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

The tool is simple, all parameters are schema-documented, and no output schema exists, so the description should ideally sketch the return shape (e.g., names vs. full paths, whether sizes/dates are included). Stating only that chapter text is excluded leaves the listing output format undefined.

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 (name, path, start) are already documented in the schema, including the defaults. The description adds no extra semantics such as filter matching rules or what a start-triggered rescan implies. Baseline 3 applies when the schema 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?

The description names a specific verb (列出) and resource (下载器保存目录中的本地文件或子目录), and adds a negative scope (不会返回章节正文) that separates it from the read_chapter siblings. It does not explicitly name the closest sibling tnd_list_downloaded_chapters, so the contrast is inferred rather than stated.

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

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

There is no explicit when-to-use or when-not-to-use guidance, but the 'does not return chapter body' clause implicitly routes content-reading tasks to the read_downloaded_chapter tools and positions this as a browsing tool. The agent can infer the right context, but nothing is stated about prerequisites or ordering (e.g., using this before a read call).

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 the returned content (status, version, save directory, config summary), but it does not state that the call is a side-effect-free read, nor whether it can fail or block, leaving the safety profile to inference.

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?

It is a single front-loaded sentence that enumerates the returned fields with no filler. The information density is high and everything stated is relevant.

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 status tool with no output schema, the description compensates by listing what the response contains, which is exactly what an agent needs to decide whether to call it. The only shortfall is the missing distinction from tnd_get_diagnostics, which likely overlaps with the configuration summary.

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 and the schema is trivially complete, so there is no parameter meaning to add. A baseline of 4 is appropriate for a no-argument tool with no semantic gaps.

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

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

The description names a specific verb (读取) and a concrete set of resources (运行状态、版本、保存目录、配置摘要), so the agent knows it is an application-level status read rather than a book or job read. It partially distinguishes itself from siblings such as tnd_get_book_status and tnd_get_batch_status by being scoped to the application itself, but it never names those alternatives.

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 reader can infer this is the tool to call when it wants the app's overall health, version, or settings. There is no explicit when-to-use or when-not-to-use statement, and no routing away from ambiguous siblings such as tnd_get_diagnostics, which is the main weakness for a 23-sibling toolset.

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 only says what is returned. It does not disclose that setting start=true triggers a new scan (a mutating, potentially slow operation), whether that scan is synchronous or how long it takes, whether prior results are replaced, or what happens when no scan has ever been run.

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 naming the resource and the return contents with no filler. It is efficient but too short to carry the behavioral weight the tool needs given the absence of annotations.

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

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

The tool is simple (one optional boolean, no nested objects, no output schema) and the description covers what comes back, which is the core need. However, for a tool whose only parameter can kick off a scan, leaving that side effect and any preconditions unexplained is a meaningful gap.

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

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

Schema description coverage is 100%, and the single parameter 'start' is already documented as a boolean defaulting to false. The description adds nothing about it, so the documented baseline of 3 applies; its main omission is the consequence of flipping start to true.

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: reading the update-scan results for already-downloaded books, plus the two values returned (updatable count, failed chapter count). It does not distinguish this from nearby siblings such as tnd_check_chapters or tnd_get_book_status, which also sound like they report chapter/update state.

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

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

There is no statement of when to call this rather than tnd_check_chapters, tnd_get_book_status, or tnd_get_status, and no note that a scan must already exist before results can be read. The only usage-shaped signal, that start defaults to false, lives in the schema rather than the description.

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

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

No annotations are supplied, so the description carries the full behavioral burden, and it only discloses one trait: body text is not returned. It says nothing about pagination behavior despite the presence of limit/offset, whether results are local-only or require network access, ordering of chapters, or what happens for a book with no downloaded chapters.

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 with the purpose front-loaded and the key exclusion (不返回正文) appended, with no filler. It is efficient, though its brevity reflects omitted content as much as disciplined editing.

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 3-parameter, no-annotation, no-output-schema tool, the description covers what is returned at a high level but leaves pagination semantics and output shape unaddressed. Adequate as a minimum-viable definition, but an agent would need to inspect the schema to use limit/offset 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 only 33% – just book_id ('数字书籍 ID') is documented, while limit and offset have bounds and defaults but no semantic explanation. The description adds no meaning beyond the schema and does not clarify units, pagination interaction, or whether book_id accepts the numeric ID shown elsewhere.

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

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

The description uses a specific verb (列出/list) plus a clearly bounded resource: chapter titles and item_id for one already-downloaded book. It also states what is NOT returned (正文/body text), which separates it from read-oriented siblings such as tnd_read_downloaded_chapters. It stops short of naming any sibling explicitly, so the differentiation is implied rather than stated.

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 phrase 已下载书籍 (already-downloaded book) implies the precondition that the book must be downloaded and hints that this is a listing/index step rather than a reading step. However, there is no explicit when-to-use vs when-not guidance and no pointer to tnd_read_downloaded_chapters or tnd_get_chapters as 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 behavioral burden. It does disclose the returned data shape (author, intro, counts, latest chapter), which is genuinely useful given there is no output schema, and 读取 implies a read-only operation. It says nothing about permissions, whether the source is remote vs local, rate limits, or what happens with an invalid or missing 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?

One front-loaded sentence with no filler; every listed field maps to real returned data. It is slightly run-on as an enumeration, but nothing is wasted and the key action leads the sentence.

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 read tool with no output schema, outlining the return contents is exactly the compensating information an agent needs. The remaining gap is sibling disambiguation against tnd_get_book_status and tnd_get_chapters, which the description never addresses.

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 book_id parameter already carries the note '数字书籍 ID'. The description adds no format, source, or validity information beyond the schema, so the documented-baseline of 3 applies.

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

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

The description names a specific verb (读取) and resource (一本书) and enumerates exactly what is returned: details, author, intro, chapter count, word count, latest chapter title. That is far clearer than the bare tool name. It does not, however, distinguish this from siblings like tnd_get_book_status or tnd_get_chapters, which could plausibly return overlapping fields.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no named alternative. The word 'preview' hints at a pre-download inspection step, but an agent facing 23 sibling tools gets no statement of when to call this instead of tnd_get_book_status or tnd_get_chapters.

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 a non-obvious ordering gotcha for the index selector. It does not state what happens if the requested chapter is not locally available (error vs fallback), nor anything about the truncation behavior governed by max_chars, both of which affect a caller's decision.

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

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

A single dense sentence front-loads the two selection modes, then immediately delivers the ordering caveat and the recommendation. Every clause carries operational value and nothing is 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 four-parameter read tool with no annotations and no output schema, the definition covers identification and ordering well but leaves gaps on failure modes (missing local chapter), on how max_chars interacts with the returned body, and on how it differs from the sibling readers. 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it clarifies that index enumerates the locally available list in online-catalog order (not download order) and that item_id is the preferred selector. That is exactly the disambiguation an agent needs when both optional selectors exist.

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

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

The description names a specific verb and resource ('读取正文' – read chapter body) plus the two ways to identify the chapter (item_id or 1-based index into the locally available chapter list). It implicitly separates this tool from the plural/latest siblings by constraining the index to the downloaded-chapter list, but it never names tnd_read_downloaded_chapters or tnd_read_latest_chapter, so an agent must infer which reader 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?

It gives parameter-level guidance ('推荐 item_id' – item_id is recommended) and warns that the index follows online-catalog order rather than download-directory position. It does not say when to choose this tool over the sibling readers (latest chapter, plural chapters) or what precondition must hold (the chapter must already be downloaded).

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 discloses one important behavioral limit (max 20 chapters per call) and the downloaded-only scope, but says nothing about read-only semantics, what happens when a requested chapter is not downloaded, or that oversized chapters are truncated rather than returned complete.

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 with the resource front-loaded and the two selection modes plus the size cap packed in without filler. It is efficient, though it has no structure to separate the read mode from the limit.

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 six-parameter read tool with full schema coverage and no output schema, the description covers the essentials: what is read (chapter body text), from where (downloaded books), how to select chapters, and the batch size ceiling. Return-shape detail is partly handled by the max_total_chars/max_chars_per_chapter parameters, leaving only 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 all six parameters are already documented, including the item_ids/start_index mutual exclusivity and the 0-means-unlimited conventions. The description merely restates that same exclusivity, adding no new meaning beyond the schema, which matches the baseline of 3.

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+resource: batch-reading the body text (正文) of one already-downloaded book, and notes the 20-chapter cap. The word 批量 implicitly distinguishes it from the singular tnd_read_downloaded_chapter, but it never names that sibling explicitly, so the agent must infer the 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?

It clarifies that the caller can use either start_index/end_index or item_ids and that at most 20 chapters come back, which is real selection guidance. However, it gives no when-to-use guidance relative to tnd_read_downloaded_chapter, tnd_list_downloaded_chapters, or tnd_read_latest_chapter, nor any precondition such as the book needing to be downloaded first.

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; “读取” only implies a non-mutating read, while “已下载” indicates the content source. It does not explain how “last” is determined, missing-chapter or error behavior, output behavior, or how a positive max_chars affects the promise of “完整正文”。

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 single sentence is compact, front-loaded with the operation, and contains no filler. Missing operational detail is assessed in the other dimensions rather than mistaken for a structural problem here.

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

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

This is minimally adequate for a simple two-parameter read tool whose required book_id and default max_chars are documented in the schema. The absence of annotations or an output schema makes the unresolved chapter-ordering, failure, and truncation behavior more consequential, though they do not prevent a basic 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 the baseline of 3 applies even though the description adds little parameter-specific information. It does not clarify positive max_chars values as a truncation limit, and its unconditional full-text wording could mislead when that non-default option is used.

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

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

“读取某本已下载书籍的最后一章完整正文” clearly states the action, resource, and scope: read the full text of a downloaded book's last chapter. It does not explicitly distinguish itself from tnd_read_downloaded_chapter or tnd_read_downloaded_chapters, so it stops short of a 5.

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

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

The phrases “已下载书籍” and “最后一章” provide a clear use case and a downloaded-content prerequisite. However, there is no routing to siblings for reading a specific chapter or multiple chapters, nor guidance on what to do when the latest chapter has not been downloaded.

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

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

The annotations only declare the generic non-read-only / non-idempotent / open-world profile; the description adds the operation-specific behavior: it re-checks local content, merges contiguous positions against the current catalog, and produces a brand-new batch rather than mutating the old one. That last point is valuable given idempotentHint=false, though it does not say what happens when no chapters qualify or whether the old batch is left untouched.

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 with no filler, and the qualifying scope comes before the exclusion and return-value note. The phrasing is compact to the point of being terse, 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 single-parameter, non-idempotent operation with no output schema, the description covers the precondition, the exact subset acted upon, and the returned identifiers. The only real gap is the edge case where no chapters are missing and how errors surface.

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 batch_id field already documents that it must match the current batch to avoid operating on the wrong one. The description adds only the qualifier that the batch must be in a terminal state, which the schema does not carry. Baseline 3 is appropriate 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 states a specific verb and resource: retry only the chapters still missing in the failed/cancelled groups of a given batch. It also scopes the result ('返回新batch_id和retry_of') and states a negative ('不会重试成功分组'), so the agent can distinguish this from the download-starting siblings 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?

It gives a clear precondition (the batch must be in a terminal state) and an explicit exclusion (successful groups are never retried), which is enough to select this over tnd_start_download or a new batch. It does not name an alternative tool or say what to do if nothing is actually missing, so it stops short of full when/when-not routing.

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

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

With no annotations supplied, the description must carry the safety profile, and it does signal a non-mutating, search-only operation. It does not disclose result volume, pagination, ranking, or whether results are cached/remote, which matters for a global search across an unknown corpus.

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 clauses, front-loaded with the search scope followed by the exclusion. No filler, though the second clause is a constraint rather than a usage route.

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 search with no output schema, the agent still lacks any sense of the return shape (list of books? metadata fields?) or result limits. The definition is adequate to call the tool but not to predict its output.

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 q already documents '书名或作者关键词'. The description adds nothing about matching behavior (exact vs fuzzy, multi-term, language), 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 (番茄书籍元数据) plus a global scope (全局), which tells the agent exactly what domain is queried. It does not name any sibling (e.g. tnd_preview_book or tnd_get_library) to sharpen the boundary, so it stops short of a 5.

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

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

The clause '本工具只搜索，不管理订阅' gives a negative boundary — this is a lookup, not a subscription or download action — which is useful given the download-heavy sibling set. However, it never says when to prefer it over tnd_preview_book or tnd_get_library, leaving the alternative choice 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 does disclose the key behavioral trait: this is an asynchronous task creator that returns a job_id rather than the content itself. It says nothing about duplicate-job behavior, failure modes, cost/quota implications, or authentication requirements, which leaves meaningful gaps for an unannotated mutation-style 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 compact clauses, front-loading what the tool does before the follow-up instruction. Every phrase earns its place with no redundancy.

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

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

For a single-parameter async-start tool with no output schema, the description covers the essential contract: it returns a job_id and the caller must poll with tnd_wait_job. Only the routing distinction versus the other start_* siblings is missing, which is a modest 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?

Only one parameter (book_id) exists and schema description coverage is 100%, so the schema already documents it as "数字书籍 ID". The description adds no syntax, format, or provenance detail (e.g. that book_id comes from tnd_search_books), so baseline 3 applies.

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

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

The description gives a specific verb and resource ("下载整本书" – download the entire book) and distinguishes scope from chapter-level siblings via "整本书", and its tool name embeds the distinction further. It stops short of naming tnd_start_chapter_download or tnd_start_discrete_download explicitly as the narrower alternatives.

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

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

It provides a clear next-step instruction ("使用 tnd_wait_job 轮询完成状态"), which is genuinely useful workflow guidance. However, it gives no guidance on when to choose this over tnd_start_chapter_download or tnd_start_discrete_download, and no prerequisites or exclusions are 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 behavioral burden. It implicitly discloses asynchronous behavior ('启动...任务', then '完成后'), which is genuinely useful, but says nothing about what the call returns (job id?), how to track progress (tnd_get_status / tnd_wait_job), behavior when the chapter is already downloaded, or whether it overwrites files.

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 filler, and the core action is front-loaded before the follow-up instruction. Nothing is wasted, though the redundancy with the schema's index description is minor slack.

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 tool with full schema coverage and no output schema, the description covers purpose and the next step. It remains incomplete on the async contract (what is returned, how completion is detected) and on sibling selection among the four start_* tools, which is the main ambiguity an agent faces here.

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 both parameters (book_id, index) are documented in the schema. The description restates 'index 是 1-based 章节序号', which duplicates the schema's '章节序号，从 1 开始' and adds no new meaning, 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: '启动单章下载任务' (start a single-chapter download task). The qualifier '单章' (single chapter) implicitly separates it from the bulk siblings tnd_start_book_download and tnd_start_discrete_downloads, though those siblings are never named.

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 clear follow-up step ('完成后用 tnd_read_downloaded_chapter 读取'), which tells the agent what to do after starting. However, it never states when to pick this over tnd_start_download, tnd_start_book_download, or tnd_start_discrete_downloads, nor any preconditions such as whether the chapter must be checked first with tnd_check_chapters.

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?

Since no annotations are provided, the description carries the entire behavioral burden. It explicitly details complex operational traits like 1-based indexing, merging continuous location tasks into intervals, and background processing.

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 definition is highly dense and efficient. It packs all essential functional requirements—input format, exclusivity, execution logic—into a single, powerful sentence without any superfluous wording.

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

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

Given the tool's complexity (handling discrete, possibly overlapping, and sequential chapter downloads), the definition is exceptionally complete. It informs the user of the necessary logical assumptions and execution environment required for correct usage.

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?

While the schema defines the parameters, the description reinforces crucial semantic constraints: that indexes are 1-based, and that indexes and item_ids are mutually exclusive, adding clarity beyond the list format.

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

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

The description clearly states the tool's purpose using a specific verb and resource: '批量下载指定章节' (Batch download specified chapters). It defines the scope and identifies the action being taken.

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

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

The description provides critical usage guidance by detailing input constraints (indexes vs item_ids must be chosen) and execution flow (skipping existing content and sequential execution), which helps distinguish it from broader bulk download 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 usefully discloses that starting a download creates an asynchronous task requiring subsequent polling. It does not cover duplicate or already-running tasks, failure behavior, or how the job identifier and eventual result are obtained.

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 front-loads the action, then succinctly covers optional scoping and the required follow-up. It contains no filler or unnecessary repetition.

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

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

For a three-parameter tool with a fully described schema, it adequately explains the basic call sequence. However, with no annotations or output schema, the missing default behavior when no range is supplied, lack of sibling differentiation, and absent job-result details are meaningful 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 coverage is 100%, and the schema already documents book_id, the 1-based range bounds, and the requirement to provide both range values together. The description only reinforces that specifying a range is optional, so the high-coverage baseline of 3 applies.

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

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

The description gives a clear verb and resource—“启动下载器的下载任务”—and adds that a chapter range can be selected. It does not explain how this general range-based starter differs from tnd_start_book_download, tnd_start_chapter_download, or tnd_start_discrete_downloads.

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

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

It provides concrete usage context: range_start/range_end optionally narrow the chapter range, and tnd_wait_job must be polled after the task starts. This is actionable workflow guidance, but there is no rule for choosing among the sibling download starters or any explicit exclusion.

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 at all, the description carries the full burden, and it does disclose the important behavior that this is a polling/blocking call that exits on completion, failure, or cancellation. However, it omits what happens when the wait times out (returning an intermediate state? error?), whether it blocks the caller, and any rate/polling interval details.

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 with the action and termination conditions front-loaded and no filler. It is under-specified rather than verbose, so it loses points only 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 simple two-parameter blocking call with no output schema, the core idea is conveyed, but key details are missing: what the returned 'final status' values look like and how timeout interacts with the result. Adequate but with clear 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 coverage is only 50%: job_id is documented but timeout_seconds has no description anywhere. The description never mentions the timeout at all, even though the default of 120s and the 5-600 range materially change behavior; the description therefore fails to compensate for the schema gap.

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 (poll/wait) and resource (download job), plus the terminal conditions (completion, failure, cancellation). An agent can tell this is a blocking wait rather than a one-shot status read like tnd_get_status, though the description never names that 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 only implied: the agent must infer that this is for blocking until a job finishes, while tnd_get_status/tnd_get_jobs are for non-blocking inspection. No explicit when-to-use, when-not, or prerequisite guidance is given.

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