Identify work page URLs on supported sites and download their media. Provide a page URL, optional subdirectory, and timeout to retrieve images, videos, or galleries.
识别四个站点的作品页面 URL 并下载。timeout 为总秒数；不接受任意文件直链。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| subdir | No | ||
| timeout | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It tells the caller that timeout is total seconds and that direct links are rejected, but it does not disclose whether the download creates files, requires authentication, has rate limits, or what side effects occur. This is a significant gap for a download tool.
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 concise sentences, front-loaded with the main purpose. However, it omits essential parameter semantics and behavioral details, making it under-specified rather than efficiently complete. It earns a 4 for brevity and structure, not for completeness.
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 tool has an output schema (per context signals), which may compensate for return-value details. But given the tool's complexity (3 params, 0% schema coverage, no annotations), the description is inadequate. It lacks guidance on when to use it, what the four sites are, and how subdir behaves. Completeness is partial at best.
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 explain parameter meanings. It only clarifies 'timeout' (total seconds). The 'url' parameter's expected format is vaguely implied by 'work page URLs from four sites,' but 'subdir' is completely unexplained. Without schema descriptions, this leaves the agent guessing on two of three parameters.
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 clearly states the tool's purpose: identifying and downloading work-page URLs from four specific sites. It distinguishes from generic download tools by specifying the accepted URL type, but it does not name the four sites or explicitly contrast with sibling tools like download_post or download_search.
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 provides a constraint (does not accept arbitrary direct file links) but offers no guidance on when to use this tool versus alternatives like search, get_post, or download_search. It doesn't state prerequisites or exclusions beyond the direct-link restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.