Downloads network files to a local cache through NapCat/OneBot 11 and returns the local absolute path for AI-driven QQ workflows.
通过 NapCat 下载网络文件到本地缓存目录并返回本地绝对路径 (OneBot 11: download_file)。 :param url: 文件下载 URL :param thread_count: 下载线程数，默认 3 :param headers: 自定义请求头列表 (如 ["User-Agent=xxx"])
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 文件下载 URL | |
| headers | No | 自定义请求头列表 (如 ["User-Agent=xxx"]) | |
| thread_count | No | 下载线程数，默认 3 |
Changes observed during successful MCP inspections.
v1.0.0Does 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 side effect (writes the file to the local cache directory) and the return value (local absolute path), but omits permission/auth requirements, rate limits, or failure behavior for a network operation.
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 purpose sentence is front-loaded and clear, but the following :param lines duplicate the schema verbatim, adding bulk without new information. Reasonably sized but not maximally efficient.
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 and no annotations, the description does partially compensate by naming the return value (local absolute path). However, for a network I/O tool with side effects, it lacks context on permissions, error cases, and cache location details, leaving notable 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 three parameters are already documented in the input schema. The description's :param lines restate the same information (URL, thread count default 3, headers format) without adding meaning beyond the schema, 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 (download) and resource (network file to local cache directory via NapCat), and clarifies it returns the local absolute path. An agent can distinguish this from upload/delete file siblings, though the description does not explicitly name any 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 description explains what the tool does but offers no guidance on when to use it versus alternatives like get_group_file_url or get_private_file_url, nor any prerequisites or exclusions. Usage must be inferred entirely by the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.