Skip to main content
Glama

generate_fetch

Copies or downloads the finished video result to a new local file, so you can save the exported output directly to a destination path.

Instructions

Copy or download the finished result into a new local file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
backendNo
destinationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a file-writing mutation ('Copy or download... into a new local file') but doesn't disclose overwrite behavior, error conditions when the generation isn't complete, whether the backend changes behavior, or file-system permissions required. The 'new local file' phrasing weakly implies it creates rather than overwrites, but this is not explicit.

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?

A single, tight sentence with zero filler and the primary action front-loaded. Every word earns its place; there is nothing redundant to trim.

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?

For a 3-parameter tool with 0% schema coverage, no annotations, and no output schema, this description is under-specified. An agent cannot determine what id to pass, which backend to select, or what destination format is expected. The unexplained 'backend' enum is especially problematic since choosing local vs azure-sora materially changes execution.

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

Parameters2/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 for the undocumented parameters — and it doesn't. It never explains that 'id' is the generation identifier to fetch, what 'backend' (local vs azure-sora) controls, or the expected format of 'destination'. The description adds no semantic value beyond the bare schema.

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 states a clear verb ('Copy or download') and resource ('the finished result') with a destination ('a new local file'). It's tied to the generation workflow, which distinguishes it from render_* and other siblings. However, it doesn't explicitly name sibling alternatives, and 'finished result' is somewhat ambiguous about what entity it refers to (a shot, a render, a media asset).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. It doesn't say to call it after generate_status reports completion, nor does it contrast with render_get_output, which could plausibly serve a similar 'get the result' role. No prerequisites or sequencing hints are provided.

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