Quady3D download asset

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

Adds real behavior beyond the annotations: writes never overwrite an existing file, the target must be an existing allowed project directory, and download access controls still apply. It also discloses the return payload (actual path, size, locally computed SHA-256), which the annotations cannot convey. Only the exact failure behavior on a refused path/overwrite is left implicit.

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?

Four short sentences, each carrying a distinct load: what it does, the non-overwrite constraint, retry guidance, return values, and the generation exclusion. The core action is front-loaded with zero 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?

With no output schema, the description supplies return values (path, size, SHA-256) and the key failure mode (no replacement of existing files), which is exactly what an agent needs. Gaps are minor: no statement of what happens on a disallowed path or how idempotent retries interact with the no-overwrite rule.

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 coverage is 0%, so the description must carry parameter meaning. It constrains target_path meaningfully (existing, allowed, non-overwriting) but says nothing about asset_id beyond 'owned result' — the required pattern and ownership precondition go unexplained.

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?

Names a specific action on a specific resource: saving an owned result to an existing allowed project directory. The closing clause 'Does not generate' distinguishes it from the generation/job siblings (quady3d_create_job, quady3d_get_job) without needing the schema.

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 scopes usage: 'Retry downloads independently of generation' and 'Does not generate' tell the agent when this tool applies and what it must not be used for. It stops short of naming a concrete alternative tool for generation, so it is clear but not fully routing.

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