Download completed studio task files into a job folder with no extra generation. Provide a taskId to receive a jobId for retrieving paths via sym_wait.
Download the files of an already finished studio task (taskId from sym_history / sym_status) into a job folder without generating anything. Returns jobId — get the paths with sym_wait.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | ||
| taskId | Yes | ||
| watermarked | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return value (jobId) and how to retrieve paths (sym_wait), which is important for agents to understand the flow. It also clarifies that it does not generate content, preventing misuse. While it doesn't detail error conditions, it sufficiently conveys the tool's behavior for a download 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 description is two sentences, front-loaded with the action and purpose, and provides necessary workflow details without redundancy.
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 is simple with three parameters and no output schema. The description covers the essential workflow: download, get jobId, use sym_wait for paths. It doesn't mention error handling or edge cases, but for this purpose it's adequate.
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?
Given zero schema coverage, the description explains all three parameters: taskId is sourced from history/status, folder indicates the destination job folder, and watermarked implies a flag for watermarked files. This provides meaning beyond the bare schema.
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 downloads files from a finished task, explicitly distinguishing it from generation by noting 'without generating anything.' It specifies the resource (files of a studio task) and the source of the taskId, making the purpose unmistakable.
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 provides clear usage context by stating the taskId must come from sym_history or sym_status, implying the tool is for post-generation downloads. It does not explicitly name alternatives for when not to use, but the 'already finished' condition and the workflow of obtaining paths via sym_wait give adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.