Skip to main content
Glama

Look at frames of an uploaded asset

look_at_asset
Read-only

PROJECT-SCOPED: this call acts only on the explicit project_id and returns the project identity with its result. YOUR OWN EYES on an UPLOADED clip or image, or a finished RENDER (storage_key from list_assets; kind='render' lists past previews/finals). Same contract as look_at: pass times=[...] (seconds into the clip) and the frames arrive as one labeled picture you read yourself, with the same tenths grid for reading positions. THE way to choose which moment of a long clip to splice in — one call over the whole clip, then insert_media with clip_start_s at the moment you saw. On a RENDER it is how you CHECK YOUR OWN WORK at exact moments — narrow times sample frame-accurately, so use it to verify a transition junction or an effect the user questions before claiming it is fine. For video clips it also returns a cached, measured temporal profile (static/frozen share, motion intensity and abrupt changes). This is sparse measurement—not continuous playback—and remains available on later turns.

Input Schema

NameRequiredDescriptionDefault
endNo
startNo
timesNo
questionNo
asset_keyYes
project_idYesRequired immutable scope for this call. Copy the id from list_projects/open_project/project_state; the active-project pointer is never used to guess.
native_resolutionNoKeep width up to 1920px: each time is its own full-detail image (no contact sheet).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / native_resolution / description
      Previous value: -"Preserve image width up to 1920px; one requested time avoids contact-sheet downscaling."New value: +"Keep width up to 1920px: each time is its own full-detail image (no contact sheet)."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover the read-only safety profile, but the description adds substantial behavior: frames return as one labeled picture with a tenths grid, measurement is sparse rather than continuous playback, a cached temporal profile (static/frozen share, motion intensity, abrupt changes) is returned for clips, and results remain available on later turns. These are real traits not derivable from structured fields.

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?

Dense but well front-loaded: the project-scoping constraint leads, then output contract, then selection/verification workflows. The caps emphasis and long sentences are slightly heavy but nearly every clause contributes unique information.

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 correctly explains the return shape (labeled picture, grid, temporal profile) and the sparse-sampling limitation. The remaining gap is the undocumented start/end/question parameters and the asset_key/storage_key naming mismatch in a 7-parameter tool.

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 only 29% (project_id, native_resolution), so the description must carry the rest. It explains times well (seconds into the clip, frame-accurate when narrow) but leaves asset_key, start, end, and question entirely unaddressed — asset_key is only obliquely implied via 'storage_key from list_assets'.

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 and resource (look at frames of an uploaded clip/image or render) and scopes it precisely to explicit-project calls. It distinguishes itself from look_at by contract ('same contract as look_at') and from list_assets by naming where storage_key comes from, so an agent can route without opening either 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?

Gives explicit when-to-use conditions: choosing which moment of a long clip to splice (then insert_media with clip_start_s) and checking your own render work at exact moments before claiming it is fine. Names the sibling tools involved (look_at, list_assets, insert_media) and the narrowing rule ('narrow times sample frame-accurately').

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.