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

Adds substantial behavior beyond the annotations: the server is a non-fetching dispatcher, the extension cold-start delay can reach 30 seconds due to the official timer floor, and stalled progress right after submission is expected. None of this is derivable from readOnlyHint=false / idempotentHint=false and it directly prevents premature retries or misdiagnosis.

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

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

Front-loads the core action and the no-bytes guarantee, then the latency caveat and the escape hatch. Three dense sentences with no filler; slightly crowded by bold emphasis but still efficient and well ordered.

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 submission tool with no output schema, the description covers the essential unknowns: where bytes come from, expected latency, and how to await results. It omits any mention of the sha256 verification path or what happens to previously queued tasks, minor gaps given the rich sibling toolset for 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 description coverage is 83%, so the schema already explains urls, wait, sha256, filename, and timeout_sec. The description reinforces wait's blocking semantics in context, but adds no syntax or format detail beyond the schema, and stateDir remains undocumented in both places. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('提交一个或一批 URL 给浏览器下载') and immediately clarifies the critical scope boundary: the server fetches no bytes and only hands the task to the extension. This cleanly separates it from siblings like chrome_download_status/progress/list, which report on rather than create 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?

Gives clear operational context (cold start up to ~30s, progress may not move immediately) and routes the agent: pass wait=true or use chrome_download_wait to obtain results. It does not state when NOT to submit (e.g., duplicate URLs) or other exclusions, so it falls short of a full when/when-not treatment.

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 description adds real information beyond the sparse annotations: irreversibility and a plugin cold-start latency of up to ~30 seconds. But it sits in tension with destructiveHint=false and idempotentHint=false — an irreversible cancel of a job is not obviously an 'additive' operation, and the description does not clarify what happens to partial download artifacts or whether cancel after completion is a no-op. Useful context, but the safety profile is left ambiguous rather than resolved.

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 action first, then the two operative facts (irreversibility, latency) in parentheses. Nothing is padded and nothing repeats the name or title. It is compact to the point of being sparse, but no sentence is wasted.

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

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

For a mutating tool with no output schema, 0% parameter coverage and only minimal annotations, the description omits everything an agent needs about the call itself: what stateDir does, what a successful cancel returns, whether an unknown/already-finished jobId errors. It correctly warns about irreversibility and cold start, but the operational gaps are significant.

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 and it says nothing about either parameter. jobId is at least self-descriptive by name, but stateDir is completely opaque — no hint about what directory it refers to, which value to pass, or what the default is. The description fails to compensate for the coverage 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?

The description states a specific verb+resource ('取消一个任务' — cancel a job), so an agent can tell it apart from read-only siblings like chrome_download_status or chrome_download_list. However it does not explicitly contrast itself with the resume/pause siblings, which are the genuinely confusable alternatives. Clear purpose, but sibling differentiation is only implied by 'irreversible'.

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 the consequence-based guidance that the action cannot be undone and that a re-download requires a fresh submission, which implicitly tells the agent this is a terminal choice rather than a pausable one. It never names an alternative tool (e.g. use chrome_download_pause if you may want to resume), so the when-to-use-vs-alternatives guidance is only implied.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds two behavioral facts the annotations cannot express: per-line truncation at 8192 bytes with a truncated=true marker, and a cold-start latency of up to ~30 seconds. Both directly affect how an agent should call and interpret results.

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

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

Three sentences, front-loaded with purpose, then the truncation caveat and the latency warning. Every sentence carries actionable information with no filler.

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

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

With no output schema, the description does supply the essential return context (fields, truncated flag) plus the escape hatch and latency caveat, which is strong coverage. The remaining gap is stateDir, left unexplained in both description and schema.

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

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

Schema coverage is only 50%: includeTerminal is documented in the schema (default true) but stateDir has no description anywhere, and the description adds no meaning for either parameter. The only identifier it mentions, jobId, belongs to the sibling tool, not to this one, so parameter semantics are not compensated.

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 in the ledger) and even names the returned fields (状态/进度/字节数). It routes the agent away from itself toward chrome_download_progress for precise lookups, so it is distinguishable from 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?

Gives an explicit conditional alternative: when output is truncated=true, switch to chrome_download_progress using jobId. That is a concrete when-to-use-other rule. It does not address the other siblings (status, wait, pause, resume, cancel) or state any exclusion for the list call 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?

Annotations only declare the safety profile (readOnly=false, destructive=false, idempotent=false); the description adds genuinely new operational context: up to ~30 seconds of extension cold-start latency and that the pause command queues until the extension wakes. It omits what happens when pausing an already-paused or completed job, which matters given idempotentHint=false.

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

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

Two tight sentences with the purpose front-loaded followed by the latency caveat; no filler. It is appropriately sized for a simple action tool, though the queueing clause is somewhat densely packed for a non-technical reader.

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

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

For a mutation tool with no output schema, the description adequately covers latency and queueing behavior but leaves both parameters undocumented and says nothing about the result or how a queued pause interacts with subsequent resume/cancel calls. Complete enough to attempt the call, incomplete for interpreting its delayed effect.

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 description mentions neither jobId nor stateDir, so the description adds no parameter meaning at all. The only hint is that some task must be identified, which is implied by the purpose rather than documented.

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

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

States a specific verb+resource: pausing a currently-downloading task, with the scope qualifier "正在下的" that distinguishes it from status/list/progress siblings. It does not explicitly name the complementary actions (chrome_download_resume, chrome_download_cancel), so differentiation rests on the agent inferring from the verb.

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 verb rather than stated: the description never says when to pause versus cancel/wait, nor any prerequisite. It does supply useful operational context (cold start up to ~30s, command queues while the extension sleeps), which is closer to behavior than to when-to-use guidance.

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

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

Annotations already cover read-only/idempotent/non-destructive, so the bar is lower, yet the description adds genuinely new behavioral context: a ~30s plugin cold-start latency window and the anti-pattern of resubmitting a job whose counters have not moved. This timing and retry guidance is exactly the kind of trait annotations cannot express.

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, purpose front-loaded followed by the operational caveat. Every clause earns its place with no filler.

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

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

The description conveys what is returned (progress and network speed) and the key latency behavior, which is adequate for a read-only progress poll with no output schema. It falls short on the undocumented stateDir parameter and on how progress/status/network speed are actually 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 description coverage is 0%, so the description must carry the parameter burden, and it largely does not. It implies jobId is the target of the lookup but gives no format hints, and the stateDir parameter is never mentioned at all.

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 (看/view) and resource (实时进度与网速 for one jobId), which is enough to distinguish it from the list/cancel/pause siblings. It does not, however, explicitly contrast itself with the closest sibling chrome_download_status, leaving the agent to infer the boundary.

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 real usage context: cold start can take ~30s, so unmoving numbers on a fresh task are normal and the user should not resubmit. That is useful 'when' guidance, but it never states when to choose this over chrome_download_status or chrome_download_wait, so the alternative-selection gap remains.

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 only give the three hints (readOnly=false, idempotent=false, destructive=false). The description adds genuinely useful behavior beyond them: Range-based resume when possible, full re-download otherwise, the restarted=true marker, and a ~30s plugin cold-start latency. It does not explicitly warn about partial-state side effects, so not a 5, but it clearly exceeds the annotation baseline.

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 action and its fallback semantics packed into a parenthetical, plus one short latency note. No filler, though the parenthetical is dense.

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 resume tool with no output schema, the description covers the key operational uncertainty (resume vs restart, cold-start latency) and the restarted=true signal. Its main gap is the complete absence of parameter guidance for jobId/stateDir, which an agent needs to invoke it correctly.

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

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

Schema description coverage is 0% and the description says nothing about either parameter. jobId (the required identifier) and stateDir (the optional state location) are left entirely undocumented, so the description does not compensate for the coverage 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 (继续/resume) and resource (一个被暂停/中断的任务), so the agent knows exactly what operation is performed. It is distinguishable from sibling pause/cancel/status by its action, though it does not name 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?

The description scopes the trigger condition to "被暂停/中断的任务" (paused/interrupted tasks), which implies when to use it. However, it never names alternatives (e.g. chrome_download to start fresh vs this to resume) or states any exclusion, leaving routing 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?

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower, and the description adds genuinely useful behavioral context: extension cold start can take up to ~30s due to Chrome's background timer floor, explaining why extensionConnected may read false initially, plus the naming of the extensionConnected field. It does not explain the circuit-breaker semantics or the response structure in depth.

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

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

Three sentences, front-loaded with what the tool checks, followed by when to use it and the cold-start caveat. Every sentence contributes, though the parenthetical about the Chrome timer is slightly dense.

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 status tool with no output schema, the description tells the agent what conditions to inspect and names one output field (extensionConnected), which is enough to call it correctly. A fuller picture of the returned shape would push this higher, but no output schema is present to rely on.

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

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

Schema description coverage is 100% and the single optional stateDir parameter is documented there, so the schema carries the load. The description adds no syntax, default, or format detail about stateDir, matching the baseline 3 for high-coverage schemas.

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

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

The description states a specific verb (查/check) plus three concrete resources: whether the local download bridge is available, whether the extension is connected, and the outbound circuit-breaker state. This clearly distinguishes it from the action-oriented siblings (download, pause, resume, cancel) that likely appear as names in the sibling list.

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 explicit when-to-use guidance: '排查第一步就敲它' (this is the first step in troubleshooting) and '任务没动静先看这里' (if a task isn't moving, look here first). That is strong context, though it does not name a sibling alternative or an exclusion case, so it falls short of a full 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds real behavioral context beyond them: the call blocks, the timeout is capped at 600s, and plugin cold start can take ~30s so an aggressive timeout produces false 'not finished' results. It does not describe what the call returns on success vs. timeout.

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

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

Two compact sentences with no filler; the core blocking behavior and its terminal states come first, and the operational caveat follows. The cold-start note is worth its length, though the 600s cap is repeated verbatim in the schema.

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

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

With no output schema, the description carries the burden of saying what comes back — it does not clarify whether the result reports per-job terminal states or which jobs timed out. stateDir is also undocumented, and zero required parameters leave the calling contract underspecified.

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% — jobIds and stateDir have no schema descriptions. The description compensates partly by explaining jobIds (the jobs to wait on) and adding real meaning to timeout_sec (600s cap plus cold-start sizing advice), but stateDir remains entirely unexplained 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?

The description gives a precise verb+resource: block until the given jobIds reach a terminal state (COMPLETE/FAILED/CANCELLED) or time out. The blocking semantics are inherently distinct from the sibling tools chrome_download_status / chrome_download_progress (presumably non-blocking polls), but no sibling is named explicitly.

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

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

Usage is implied rather than stated: an agent infers it should call this when it needs to await completion. There is no explicit 'use this instead of polling status' or 'do not call when you just need a snapshot' guidance, though the cold-start/timeout warning does steer practical setup.

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