download_resultDownload result files for an OpenAaaS task and return each file’s full path, with options to select a file ID or download all results.
下载任务结果文件并返回每个文件的完整路径
file_id: 指定要下载的文件 ID，不指定则默认下载第一个 zip 文件或第一个文件
download_all: 是否下载该任务的所有结果文件
返回结果中会明确列出每个文件的完整路径，读取文件时请直接使用这些路径，不要推测子目录。
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | ||
| file_id | No | ||
| task_id | Yes | ||
| download_all | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.6Input schema / properties / server / defaultPrevious value: -"default"New value: +""v0.1.3v0.1.2v0.1.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 discloses useful behavior about default file selection and returned paths, including a warning not to guess subdirectories, but it does not mention save location, overwrite behavior, permissions, or other side effects.
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 front-loaded with the main action, then uses concise bullets for parameter behavior and a short warning about paths. Every sentence adds useful information without waste.
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, so return-value details are less necessary, and the description still explains returned paths. However, with no annotations and incomplete parameter coverage, it should do more to explain the server parameter, required task_id semantics, and when this tool is preferred over siblings.
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 compensate. It documents file_id and download_all well, but task_id is only implied and the server parameter is entirely undocumented.
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 and resource: downloading task result files and returning each file's full path. It is clear what the tool does, but it does not differentiate itself from siblings such as list_files or get_task.
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 explains default file selection and download_all behavior, which gives implied usage. However, it does not say when to use this tool instead of list_files or get_task, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.