Download a finished asset into the workspace

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations state readOnlyHint=false, openWorldHint=true, and destructiveHint=false, but the description adds concrete behaviors: writes multiple file types, extracts textures to a textures/ subdirectory, writes asset.json, and never overwrites existing workspaces. It also explains the urgency of expiring URLs, which is not captured by annotations. No contradictions.

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 a cost note ('FREE: no credits') and then a compact enumeration of what is downloaded. Every phrase adds value: the extraction detail, the asset.json provenance, the urgency trigger, and the no-overwrite guarantee. No redundancy or filler.

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?

For a download tool with no output schema, the description conveys all essential operational facts: what is downloaded, where textures go, the asset.json side effect, the timing constraint, and the handling of repeated calls. It answers the key questions an agent would have to call it correctly. The lack of an explicit return value is acceptable given the action-oriented nature, and the description is otherwise complete.

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 covers 67% of parameters (destination and extractTextures have descriptions; assetJobId has none). The description adds meaning beyond the schema: it explains the output root concept via 'workspace folder', specifies the texture extraction location ('textures/'), and clarifies the non-overwrite behavior tied to destination. It does not explicitly describe assetJobId but implies it from get_asset_job, which is sufficient context.

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 ('downloads'), resource ('completed asset job'), and destination ('local workspace folder'), enumerating exactly what gets downloaded (model, PBR variant, preview, source reference) and what is extracted/extended (textures, asset.json). It also implicitly differentiates from get_asset_job by referencing it as the prerequisite, and from other asset tools by focusing on fetching a finished job.

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?

Explicitly instructs when to call ('as soon as get_asset_job reports "ready"') and why (provider URLs expire). Also warns about repeat-download behavior (new suffixed folder instead of overwrite), which guides an agent on idempotency handling without needing to guess.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.