Skip to main content
Glama

workbench_download

Download a completed 3D asset for a given job, then validate and archive it locally without triggering regeneration.

Instructions

Select the matching completed asset, download via official UI, validate and archive. Never generates again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYes
format_nameNoauto

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of disclosing behavior. It does disclose the multi-step behavior: downloading via official UI, validating, archiving, and never generating again. However, it omits details like authentication requirements, what 'archive' does to data, and whether the operation has side effects beyond the download.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, approximately two short sentences, and every phrase adds information: the selection criterion, the download mode, validation, archiving, and the non-generation guarantee. There is no redundant fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool description provides a high-level workflow but is incomplete for actual invocation. It lacks any explanation of the input parameters, expected output, or operational prerequisites beyond 'completed asset.' With no output schema and no annotations, this is a material gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate by explaining the parameters, but it never mentions job_id or format_name. 'Matching completed asset' vaguely implies job_id, but format_name is completely unaddressed. An agent cannot reliably know how to set format_name from this description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific workflow: select a completed asset, download it, validate, and archive. It clearly describes the resource and action, and the line 'Never generates again' helps distinguish this download tool from generation-oriented siblings, even though no sibling is explicitly named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Select the matching completed asset' provides clear context that this tool should only be used when a completed asset already exists. 'Never generates again' is an explicit exclusion, telling the agent this tool is not for generation. It does not name alternative tools, but the usage boundary is reasonably clear.

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