Fetches an asset from Etchv storage or a customer bucket and saves it to a new local file without overwriting existing files.
Download an asset into a new local file. Uses Etchv storage or the selected customer bucket. Never overwrites files. Scope: assets:read.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | ||
| output_path | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic safety profile (non-read-only, non-destructive, non-idempotent, open-world). The description adds genuinely useful behavior: it never overwrites existing files, which resolves the tension between readOnlyHint=false and destructiveHint=false, and it names the required scope assets:read.
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, purpose front-loaded, and each sentence carries distinct information (target, storage source, overwrite policy, scope). Minor waste in the internal 'Etchv storage' jargon that an agent may not recognize.
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?
Covers target, storage backend, overwrite policy, and auth scope, which is decent for a write-to-disk tool with no output schema. It still omits the return value (e.g., resulting file path) and the meaning/format of both parameters, leaving real gaps.
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% and neither asset_id nor output_path is described. The phrase 'into a new local file' only hints at output_path and says nothing about the asset_id format, path constraints, or what happens if the path exists.
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?
Specific verb+resource (download an asset) plus a distinguishing detail: it writes to a new local file, unlike get_asset which presumably returns metadata. It never names a sibling explicitly, so it lands just short of the top tier.
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?
No statement of when to choose this over get_asset, list_assets, or store_asset, and no prerequisites beyond the permission scope. The storage-source sentence describes mechanism, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.