chrome_download_listLists Chrome download tasks with status, progress, and byte counts, flagging truncated results for large ledgers. Use job IDs for exact progress queries.
列出账本里的下载任务（含状态/进度/字节数）。账本很大时本工具会截断到单行 8192 字节以内并标 truncated=true，届时请用 jobId 精确查（chrome_download_progress）。插件冷启动最长约 30 秒。
| Name | Required | Description | Default |
|---|---|---|---|
| stateDir | No | ||
| includeTerminal | No | 是否含终态任务（默认 true） |
Changes observed during successful MCP inspections.
v0.3.0Does 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.