blender_download

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds valuable behavioral context beyond annotations: it explicitly states the download is size-capped, only http/https are allowed, and nothing downloaded is ever executed. It also mentions the tool reports size and SHA-256, which is a behavioral outcome. This goes beyond what annotations alone convey, though it doesn't detail failure modes or side effects like file overwriting.

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 three sentences with zero waste. The core action is front-loaded in the first sentence, safety constraints follow, and the workflow suggestion is last. Every sentence earns its place, and the structure is easy to scan.

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 tool with 7 parameters and no output schema, the description covers the essential context: what it does, safety constraints, and how it fits with a sibling tool. It doesn't explain return values in detail, but the description already states it reports size and SHA-256, which is sufficient for an agent to know what to expect. The main gap is not describing what happens on checksum mismatch or file overwrite behavior, but the schema's sha256 description covers the mismatch case.

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 71%, so the schema already documents most parameters. The description adds context that the download is size-capped and reports SHA-256, which maps to max_bytes and sha256 parameters. It also clarifies the tool's role in a pipeline (combine with blender_import_asset), which helps an agent understand why parameters like directory and filename matter. However, it doesn't add detail on timeout or response_format beyond what the schema provides, so a 4 is appropriate rather than 5.

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: 'Fetch a URL to a local file and report its size and SHA-256.' It clearly distinguishes this from sibling tools like blender_import_asset by noting it only downloads and does not execute, and it explicitly suggests combining with blender_import_asset for a full workflow. This makes the tool's purpose unambiguous.

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 explicitly says when to use this tool ('Combine with blender_import_asset to pull a model straight onto the scene') and what it is not for ('nothing downloaded is ever executed'). It also states constraints (only http/https, size-capped) that guide safe usage. This is strong guidance for an agent deciding between download and import tools.

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