Skip to main content
Glama

Get the zip of every clip

get_whole_video_zip
Read-onlyIdempotent

The download link (valid for an hour) for the zip export_whole_video_zip built, once wholeVideo.zip.status is ready.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>"
    },
    "name": "get_whole_video_zip"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectIdYesThe project id (from create_project_from_url, create_project_from_file, get_upload_link, start_upload or list_projects).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's added value is the disclosure that the returned link is valid for only an hour — a genuinely useful, non-obvious behavioral constraint — plus the readiness gate on the export. It says nothing about error behavior when the export is not ready, but that is a modest gap.

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

Conciseness4/5

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

One sentence, with the key payload (download link) and its expiry front-loaded. The only waste is the clumsy construction 'the zip export_whole_video_zip built', which could be a clean clause naming the sibling tool.

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

Completeness4/5

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

For a simple one-parameter read tool with full annotation coverage and no output schema, the description covers what is returned (a link), its lifetime, and the readiness precondition. Only the failure mode when status is not ready is left unstated, which is minor given the tool's simplicity.

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

Parameters3/5

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

There is a single parameter with 100% schema description coverage, and the schema already explains where the projectId comes from, including valid sibling sources. The description adds no further meaning about projectId or how it relates to the zip export, so the baseline 3 applies.

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 names a specific resource and outcome — a download link for the zip produced by export_whole_video_zip — which is distinguishable from the sibling export_whole_video_zip (that one initiates the export; this one retrieves the result). The phrasing 'the zip export_whole_video_zip built' is grammatically awkward, which slightly blunts the clarity, but an agent can still tell what it gets back.

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?

It states a clear precondition: call it once wholeVideo.zip.status is ready, implying the agent should wait on status rather than call immediately. It does not explicitly name which sibling to poll (get_status vs get_whole_video) or say what happens if called too early, so the routing guidance is contextually implied rather than spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.