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 one important behavioral trait — the task's breakpoint state is preserved and resumption is possible — but it omits what state the task ends in (cancelled vs removed from list_downloads), whether partial data remains, and whether the operation is immediate or requires permissions.

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 that front-loads the action and uses the parenthetical only for the semantically important qualifier. Nothing is wasted and nothing is buried.

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 mutation with no annotations and no output schema, the description covers the core action and its key side effect, but leaves the id's origin/semantics and the resulting task state unspecified — gaps an agent would have to resolve by trial or by reading siblings.

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

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

Schema description coverage is 0% and the single 'id' parameter is undocumented in the schema. The description's reference to '一个下载任务' implies the id identifies a download task, adding marginal meaning, but it never confirms the identifier's source (e.g. from list_downloads or start_download) or accepted 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 states a specific verb+resource: cancelling a download task, with the parenthetical clarifying the scope (state is retained). It is distinguishable from start_download/download_status/wait_download by the cancel action, but it does not explicitly name any sibling or contrast itself with a delete-like alternative.

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 parenthetical '保留断点状态，可再次续传' implies when this is appropriate (stop now, resume later), which is useful inference, but there is no explicit when-to-use statement, no preconditions, and no named alternative for a non-resumable stop.

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 useful traits: AES-128 decryption is handled automatically, master playlists allow bitrate selection, and downloads are resumable. It does not state permission requirements, rate limits, or what happens on failure/partial output.

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

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

Two tightly packed sentences with no waste, and the core action is front-loaded ahead of the supporting capabilities.

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 9 parameters, 33% coverage, no annotations, and no output schema, the description is far too thin. Six parameters and the return/error behavior are left entirely unexplained for a fairly complex tool.

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

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

Schema coverage is only 33%, so the description must compensate. It hints at bitrate selection (quality) and resumability (restart), but proxy, output, headers, insecure, connections, and keep_segments are undocumented in both schema and description.

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 (下载/download), a specific resource (HLS/m3u8), and the outcome (合并为单文件/merge into a single file). It is clearly distinct from generic siblings like start_download, though it does not explicitly contrast them.

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 lists supported features (master bitrate selection, AES-128, resumable) but gives no guidance on when to use this instead of start_download or other siblings, 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does disclose the key scope behavior (id returns one task, no id returns all tasks), but says nothing about progress fields, permissions, or how unknown ids behave.

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

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

Two short sentences, front-loaded with the core purpose, with the id condition immediately following. No wasted text.

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

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

This is a simple read tool, but with no output schema and no annotations, the description should clarify return shape (task/progress fields) and edge cases. It only defines single-versus-all 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?

The single optional id parameter has 0% schema description coverage, and the description fully explains its semantics: provide id to query one task, omit it to return all tasks. It does not specify the id format, but otherwise compensates well.

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 the specific verb (查询, "query") and resource (下载进度, "download progress"). It also explains the optional-id behavior, but does not distinguish this tool from sibling list_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?

Implies when to call it with an id versus without one. However, it does not name alternatives such as list_downloads or wait_download, so the agent must infer the boundary between them.

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 burden. It conveys that this is a read of tasks plus their status, but says nothing about ordering, pagination, or behavior when there are no downloads, and gives no explicit read-only safety statement.

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

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

A single front-loaded sentence with no filler; the scope and the returned data are stated immediately. Every word earns its place.

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

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

With no output schema, the description is the only source for return-shape information, and it only says 'tasks and their status' without describing fields or format. Adequate to select the tool but thin for an agent that needs to interpret the result.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies per the rubric.

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

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

States a specific verb (列出/list) and resource (下载任务/download tasks) plus a scoping qualifier (当前会话内/within the current session). The session scoping meaningfully distinguishes it from siblings like queue_list and download_status, 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?

The description implies usage (inspect all downloads in the current session) but gives no explicit when-to-use guidance and never mentions alternatives such as download_status for a single task or queue_list for queued items. An agent must infer the boundary itself.

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 fields and that no file content is fetched, but says nothing about redirect handling, failure behavior, auth/cookie implications beyond the headers param, or side effects of the network request.

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 return payload enumerated and the key non-download caveat at the end. No wasted words.

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

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

With no output schema, the description correctly lists the returned fields, which is the essential information. Remaining gaps are error/redirect behavior for a tool that performs a live network fetch.

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%, including url, proxy, headers and insecure, so baseline is 3. The description adds no meaning beyond the schema for any of the four 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?

States a specific verb (探测/probe) and resource (URL) and enumerates exactly what is returned: file size, Range support, ETag, filename, Content-Type. The closing '不下载' (does not download) sharply separates it from the download-oriented 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?

'不下载' implicitly frames this as the metadata-only precursor to start_download/download_hls, giving clear context for selection. It never explicitly names a sibling or states when not to use it, 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?

With no annotations, the description carries the full burden. It discloses key traits: persistence via SQLite, retention after process exit, and resumable downloads. However, it omits critical queue semantics such as whether adding starts the download, what is returned (e.g., job ID), duplicate handling, and error behavior.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though given the tool's complexity it could benefit from a second sentence to clarify usage without becoming verbose.

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

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

For a tool with 7 parameters, no annotations, no output schema, and very low schema coverage, the description is incomplete. It conveys the core action and persistence, but omits parameter meanings, return behavior, and queue interaction with siblings like queue_run.

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?

Seven parameters exist with only 14% schema description coverage, and the description adds no meaning for any parameter. It does not explain url, proxy, output, headers, priority, limit_bps, or connections, leaving the agent with almost no parameter guidance beyond basic types.

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: '把下载加入持久化队列（SQLite）' (add download to persistent queue). It clearly distinguishes itself from simple start_download by emphasizing persistent queueing and resumability, but it does not explicitly name or compare with siblings like start_download or queue_run.

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 guidance or alternatives are provided. The description only states the capability; it does not tell the agent when to prefer queue_add over start_download or queue_run, nor mention prerequisites.

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 hints at the returned content (status counts plus task details) but omits pagination, ordering, result limits, and any explicit confirmation that this is a side-effect-free read.

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

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

A single compact sentence with the resource and returned payload front-loaded; nothing is redundant. It is terse rather than padded, though it borders on under-specification.

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

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

For a tool with no annotations, no output schema, and zero parameter documentation, the description leaves essential calling details (status semantics, result shape beyond a summary, ordering) unaddressed despite the large sibling set it must compete against.

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 single 'status' parameter is undocumented. The phrase '按状态统计' hints that status relates to grouping/filtering, but valid values, whether it filters or aggregates, and its default are all unstated.

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 (查看/view) and resource (队列/queue) plus the content returned: status statistics and task details. This clearly separates it from write-oriented siblings like queue_add or queue_run, though it never names an alternative to disambiguate 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?

Provides no guidance on when to use this versus the other queue tools; the read-only intent is only implied by the verb '查看'. No prerequisites, no exclusions, no stated alternative.

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 not say whether removal is permanent, whether an in-flight task is aborted or merely dequeued, or what happens if the id does not exist — all critical for a destructive queue mutation.

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 with zero padding and the action front-loaded. Brevity is appropriate, though it borders on under-specification rather than tight 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 destructive mutation with no annotations, no output schema, and an undocumented parameter, the description leaves too much unspecified — permanence, failure behavior, and id semantics are all unaddressed.

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

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

Schema coverage is 0% and the single parameter 'id' is undocumented in both schema and description. The description does not clarify whether the id refers to a queue entry, download id, or task id, leaving the only input ambiguous.

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 (a task in the queue), which is enough to separate it from queue_add and queue_list. It stops short of explicitly naming a sibling alternative, but the 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?

There is no guidance on when to use this versus cancel_download or queue_retry, nor any mention of prerequisites such as whether the task must be idle or already running. The agent must infer the usage context entirely.

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 one meaningful side effect (state moves to pending), but omits whether this counts against a retry limit, whether it errors for non-failed tasks, whether it is idempotent, whether a separate queue_run is needed to actually execute, and what permissions are required.

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 with the state transition front-loaded and no filler. It is appropriately sized for the tool, though its brevity reflects under-specification rather than 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?

With no annotations, no output schema, and an undocumented required parameter, the description should do more work. It leaves open what the return value is, whether the task re-executes immediately or waits for queue_run, and whether retries are bounded.

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% for the single required `id` parameter, and the description never mentions it. The agent can only infer that `id` is the identifier of the failed task. This is the one gap the description was best positioned to close and it does not.

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 with the resulting state transition: reset a failed task to pending. That distinguishes it cleanly from the queue_* siblings (add/run/list/remove) without needing to name them. It stops short of a 5 only because the object of the action ('task') is never tied to the lone `id` parameter.

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 'failed task' implicitly scopes usage to tasks in a failed state, which is useful context. However, it never states when to prefer this over queue_run or queue_add, nor what happens if the task is not failed. Usage must be inferred from the state transition itself.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the call drains the entire queue in parallel and returns final per-task status, but says nothing about blocking/long-running behavior, failure handling for individual tasks, or whether the operation is resumable or cancellable.

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 front-loaded and no filler. Every clause contributes: the drain-until-empty scope, the parallel execution mode, and the return value.

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

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

There is no output schema and no annotations, so the description must compensate. It does state that per-task final statuses are returned, but omits error behavior, empty-queue behavior, and blocking characteristics for what is effectively a long-running batch operation.

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 'parallel' parameter is documented in the schema with its default of 2. The description's mention of '并行下载' corroborates that parameter but adds no syntax or semantics beyond it, so the baseline of 3 applies.

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

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

States a specific verb and resource: consume the queue until it is empty, with parallel downloads, returning each task's final status. It clearly differs from siblings like queue_add, queue_list, queue_remove and queue_retry, though it never names them 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?

The phrase 'consume the queue until empty' implies this is the execution trigger for a previously populated queue, but there is no explicit when-to-use guidance, no statement about interaction with queue_add or cancel_download, and no note on whether it should be called when the queue is already empty.

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. It does add real behavioral context: the operation is asynchronous, it returns a task id, and it supports resume. However, for a 14-parameter mutation-ish operation it says nothing about proxy/auth requirements, rate-limit effects, what happens on a failed checksum, or whether an existing output file is overwritten.

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 sentences, zero filler, and the core action is front-loaded before the async/return-value detail. Each sentence earns its place. It is arguably thin for the tool's complexity, but that is a completeness issue rather than a structure issue.

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

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

This is a 14-parameter tool with no annotations, no output schema, and several tuning knobs (connections, limit_bps, dynamic_chunks, verify_seam, open_range) whose interactions matter. The description covers only async, task-id return, and resume, leaving the agent without enough context to configure or reason about the call. It does correctly disclose the return value, which partially offsets the missing 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 71%, so most parameters are already documented in the schema and the baseline is 3. The description only echoes one parameter ('支持断点续传' ↔ resume) and adds no syntax, defaults, or interaction guidance beyond that. It neither compensates for the undocumented proxy/headers/insecure params nor extends the documented ones.

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 adds two meaningful qualifiers: async execution and multi-connection chunking. It names download_status as the progress-tracking companion, so an agent can place it in the workflow. It does not, however, distinguish itself from download_hls or queue_add, which are plausible alternatives for starting a transfer.

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 ('start a download task') and points to download_status for progress, which is helpful routing. But it never says when to pick this over download_hls or the queue_add/queue_run pair, nor does it state prerequisites or when a task should be cancelled instead. Usage is implied rather than specified.

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

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

With no annotations, the description must carry behavioral disclosure. It usefully states that the call blocks until completion or timeout and returns final status, but does not clarify timeout behavior, whether it polls or waits server-side, or whether cancellation affects the wait.

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

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

The description is a single, front-loaded sentence that communicates the core action and return without any filler. It is appropriately sized for a simple wait operation.

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 tool with no output schema and no annotations, the description covers the basic invocation intent but leaves important context unspecified: the meaning of id, exact timeout semantics, return shape beyond 'final status', and how it relates to sibling status-checking tools.

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

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

Schema coverage is only 50%: the id parameter is undocumented in both schema and description, and timeout_sec is already described by the schema. The phrase 'or timeout' does not add meaning beyond the existing timeout_sec 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 specific verb and resource: blocking-wait for a task to finish or timeout, then returning final status. It implies a distinction from non-blocking status checks like download_status, but does not name or explicitly contrast that sibling.

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

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

It states the operation but offers no explicit when-to-use guidance, no prerequisites, and no alternatives such as download_status or polling. The blocking nature implies a use case, but the description does not articulate when this tool should be chosen over siblings.

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