Skip to main content
Glama

Read an asset

read_asset
Read-onlyIdempotent

Read an uploaded asset's pixels, metadata and readiness, and its analysis: every upload is analyzed after it encodes, and analysis.brief then says what happens, what is on screen and heard, the moments to use or cut (with times), the lines worth quoting, and the problems; the sound's music, effects and reactions with times. hasAudio says whether a video has a sound track. id comes from search_assets. To look closely at a video file, whether or not it is on the film (preview_frame and preview_range draw only the film): startSeconds and endSeconds draw a contact sheet of only that range of the file, and times draws up to 4 frames of the file large. Use them to time an action to a tenth of a second or to check a detail. Such a call answers with the picture and its legend, not the brief.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
timesYesSeconds of a video file to see as large frames, 1 to 4, in one picture in time order with each time on its frame. Use it to check a detail or the exact moment of an action. Not with startSeconds and endSeconds. null (or leaving it out) draws a contact sheet.
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.
endSecondsYesWhere that range ends, in seconds of the file, after startSeconds. The sheet has up to 16 tiles with their times, so a range of 2 seconds shows a tile about every 0.13 seconds. A range past the end of the file stops at its end.
startSecondsYesWhere a contact sheet of part of a video starts, in seconds of the file. Pass it with endSeconds. null (or leaving it out) draws the whole file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/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, closed-world), so credit goes to the added context: the description discloses that hasAudio signals a soundtrack, that a call carrying times/range returns a picture plus legend rather than the brief, and what analysis.brief contains. It does not explain how 'readiness' is signaled, a minor 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?

The core purpose and the routing to sibling tools are front-loaded, then the analysis/preview details follow. Sentences are dense and occasionally sprawl (the long analysis.brief enumeration), but nearly every clause carries information an agent needs.

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?

With no output schema, the description carries the return-value burden and does so well: it enumerates brief contents, the picture+legend response mode, and the hasAudio flag. The only lapse is that 'readiness' is mentioned but never explained for a tool whose name implies tracking an async upload.

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

Parameters4/5

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

Schema coverage is 80%, so the baseline is 3, but the description adds real semantics: that times and startSeconds/endSeconds are mutually exclusive, that times draws up to 4 large frames while the range draws a contact sheet of ~16 tiles, and that the response format differs for those calls. This meaning goes beyond the already-rich schema descriptions.

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?

The opening states a specific verb+resource (read an asset), enumerates what is returned (pixels, metadata, readiness, analysis), and names the sibling tools it is not (preview_frame and preview_range draw only the film). An agent can distinguish it from the preview siblings without opening a schema.

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?

It explicitly routes the agent: id comes from search_assets, and for close video inspection it names preview_frame and preview_range as the alternatives that draw only the film, then explains what startSeconds/endSeconds/times do instead. It even gives the motivating use case (timing an action to a tenth of a second, checking a detail).

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.