Skip to main content
Glama

Look at frames of the video

look_at
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 the footage. Pass times=[...] (1-8 exact source seconds of the MAIN video) and the frames at those moments come back as ONE timestamp-labeled picture in your own context — you see the footage yourself and judge it directly (composition, where the subject is, clear space for text, what a moment looks like). Every frame carries a faint tenths grid ((0,0) = top-left): READ aim points, cx/cy and rects off its labels instead of estimating. start/end still work as a range sampled evenly. OR pass output_times=[...] to see the ASSEMBLED PROGRAM instead: output seconds of the current edit, resolved through the EDL — kept footage AND spliced inserts both sample correctly, each tile labeled with its scene number, in TRUE output geometry (canvas fit and any active zoom applied — so you can SEE an aimed zoom's framing before rendering) — THE way to check what the viewer sees at a moment of the EDITED video ('the second scene') without rendering. Look as often as you need — there is no cap on looking; before aiming anything and before disputing what a user saw, look. Batch the moments you need into ONE call with several times rather than a string of separate calls. The filmstrips already gave you the whole video at a glance — use look_at for the CLOSER look: exact framing, small text, a precise instant. The transcript is ASR and can be wrong; inspect confidence and sentence context using get_words / the transcript — never look to lip-read or guess a word. IMPORTANT: the assembled geometry view composes picture cards (backdrop and windows) and erase patches but omits burn-ins (captions, text, motion graphics, grade). Set rendered=true after render_preview to inspect the CURRENT preview's real pixels—including captions, text, overlays and grade. In rendered mode output_times (or times) are output seconds and any useful set can be batched for caption QA. overlay (with times or output_times) marks what a device decision needs: 'matte' tints the person matte (measuring it first if needed), 'free_space' shades faces, UI bands and the watermark and outlines the free rectangles for type, 'beats' adds a ruler of stresses, cuts, the user's beats and device landings.

Input Schema

NameRequiredDescriptionDefault
endNo
startNo
timesNo
overlayNo
questionNo
renderedNo
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.
output_timesNo
native_resolutionNoWith rendered=true, keep width up to 1920px: each time is its own full-detail image (no contact sheet), no re-encode.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / overlay
      Added value: +{
      +  "enum": [
      +    "matte",
      +    "free_space",
      +    "beats"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / native_resolution / description
      Previous value: -"With rendered=true, preserve image width up to 1920px; request one time for full-detail approval pixels without another encode."New value: +"With rendered=true, keep width up to 1920px: each time is its own full-detail image (no contact sheet), no re-encode."
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations mark it read-only/non-destructive, and the description adds substantial behavior beyond that: project scoping is mandatory, there is no cap on calls, the assembled-geometry view includes picture cards and erase patches but OMITS burn-ins (captions, text, grade), and rendered mode is required to see real pixels. These caveats materially change how an agent should interpret a result.

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?

Front-loads the two most important facts (project scoping, 'your own eyes'), and most sentences carry distinct operational content across four interaction modes. It is dense and long, with some run-on segments, but little is pure filler.

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 9-param, multi-mode tool with no output schema, the description covers return shape (one labeled picture, tiles, grids), mode behavior, and the render/overlay caveats thoroughly. Only 'question' and the native_resolution interplay with rendered mode are left to the schema.

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 only 22%, so the description must compensate, and it largely does: times = 1-8 exact source seconds of the main video, start/end = evenly sampled range, output_times = output seconds resolved through the EDL, overlay values (matte/free_space/beats) with their meanings, and rendered semantics. 'question' is never explained, leaving one parameter unaccounted for.

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 concrete verb and resource — sampling exact source seconds of the main video and returning them as one timestamp-labeled image 'in your own context'. It explicitly separates itself from siblings like the filmstrip overview, the ASR transcript/get_words, and the rendered-preview path, so an agent can route without opening any 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 (before aiming, before disputing a user, for a closer look than filmstrips), when-not (never use it to lip-read or guess a word — use get_words/transcript), and mode selection rules (times vs output_times vs rendered=true after render_preview). Batching guidance ('several times into ONE call') is also 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.