Skip to main content
Glama

Wait for an asset

wait_for_asset
Read-onlyIdempotent

Wait until assets are usable, then return each one's placement lines. Takes up to 20 Asset IDs per call (assetIds), so split a longer list over several calls: imports, generations, your own uploads, and uploads the user started, which search_assets lists with preparing set while they upload or encode. Every upload is analyzed after it encodes (usually under 15 seconds): an asset still analyzing can be seen but not placed, and this waits for that too. A ready asset comes with its brief: what happens, what is on screen and heard, the moments to use or cut, the lines to quote, and the problems; read_asset has the whole brief. Answers when all of them are ready or failed, each with its reason (a plan limit says so). One call waits at most 50 seconds (waitSeconds, null for the longest wait); if some are still processing or analyzing then, it names them with their progress: start on the ready ones, tell the user, and call wait_for_asset again with those ids. skipAnalysis true lets the assets through without waiting for their analysis. Use this after an import or upload, and whenever an asset is still uploading, processing or analyzing, before placing or analyzing it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
assetIdsYesEvery Asset ID to wait for, in one call: all the uploads, imports or generations the next step needs. 1 to 20.
projectIdYesThe project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.
waitSecondsYesSeconds to wait for the assets to become usable before answering, 0 to 50. null waits 50.
skipAnalysisYestrue: use the assets now, without waiting for their analysis (transcript, shots, sound, brief); it keeps running and read_asset shows it later. Only when the user wants the asset used at once. null or false waits for the analysis.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds substantial behavioral context beyond them: the 20-ID cap, the 50-second ceiling, the ~15-second analysis norm, that an analyzing asset can be seen but not placed, failure reasons, and the timeout/retry loop with progress reporting.

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?

The core action is front-loaded in the first sentence and nearly every sentence carries actionable detail (limits, timeout, retry). It is a dense, somewhat run-on block, with mild redundancy against the schema's own parameter text, but no filler.

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

Completeness5/5

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

For a complex polling tool with no output schema, it covers what is returned (placement lines, the brief's contents, failure reasons), the timeout contract, and the exact follow-up procedure on partial completion — enough for an agent to drive it correctly.

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?

Schema description coverage is 100% and the schema already documents assetIds limits, waitSeconds 0-50/null semantics, projectId defaults, and skipAnalysis behavior. The description largely restates these (20 per call, null = longest wait), so it adds little parameter meaning beyond the schema; baseline 3 applies.

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

Purpose5/5

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

States a specific verb+resource with scope: 'Wait until assets are usable, then return each one's placement lines.' It is clearly separable from siblings like wait_for_jobs (jobs, not assets) and read_asset (the full brief), which it explicitly cross-references.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ('after an import or upload, and whenever an asset is still uploading, processing or analyzing, before placing or analyzing it'), a batching rule (20 IDs per call, split longer lists), and a conditional for skipAnalysis ('Only when the user wants the asset used at once').

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.