取消

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.