Downloads a shared material file to a local directory and returns its path, size, and SHA-256 hash. Duplicate filenames are auto-renamed unless overwrite is enabled; redemption is not automatic.
流式下载到本地并返回路径、大小、SHA-256；不会自动兑换。默认同名文件自动改名。
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | ||
| overwrite | No | ||
| output_dir | No | ||
| material_id | Yes | 平台对象 ID，正整数 |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the download is streamed, writes to local storage, returns path/size/SHA-256, does not auto-redeem points, and auto-renames same-name files by default. These are concrete behavioral traits that help the agent predict side effects, though permissions and overwrite behavior are not fully explained.
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 compact sentence with the core action front-loaded and no wasted clauses. Each semicolon-separated detail adds distinct value, including return values, redemption behavior, and filename handling.
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?
An output schema exists and the description mentions return values, while annotations cover the safety profile. However, the low parameter-description coverage and missing usage guidance around redemption alternatives leave notable gaps for an agent deciding how to call the tool 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 only 25%, with material_id being the only documented parameter. The description hints at filename-collision behavior with '默认同名文件自动改名', but it does not explain overwrite or output_dir semantics, leaving most parameters 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?
The description states a specific action and resource: stream-downloading a material to local storage, returning path, size, and SHA-256. It distinguishes itself implicitly from URL-only siblings like share_get_download_url by emphasizing local streaming, but it does not explicitly name alternatives.
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 guidance is given for when to use this tool versus share_get_download_url, share_purchase_material, or share_redeem_points. The note '不会自动兑换' is an important caveat, but it stops short of telling the agent what to do instead when redemption is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.