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 omits burn-ins. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNo
startNo
timesNo
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, preserve image width up to 1920px; request one time for full-detail approval pixels without another encode.

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 declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds rich behavioral context beyond annotations: output is a single timestamp-labeled picture with a tenths grid, both source and assembled modes sample correctly, rendered mode omits burn-ins unless rendered=true, and there is no call cap. It also explains the grid for reading aim points, which is non-obvious and valuable.

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

Conciseness3/5

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

The description is very long and dense, with many clauses and parentheticals. It is front-loaded with the scoping warning and main usage, but overall it is verbose and could be condensed without losing critical information. Some sentences repeat or elaborate beyond necessity, making it harder to scan quickly.

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?

Given the tool's complexity (two modes, rendered behavior, grid), the description covers most operational details. However, it does not clarify what happens if both times and output_times are provided, nor does it explain the 'question' parameter's purpose. With no output schema, these omissions are noticeable, but the description is still fairly complete for an agent to use correctly.

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 25% (2 of 8 params described). The description compensates well for times, output_times, start/end, and rendered by explaining their semantics and mode differences. However, the 'question' parameter is not explained anywhere, and native_resolution is only in the schema. This leaves a minor gap but the core parameters are well-covered.

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 description clearly states what the tool does: it returns frames from the main video at specified times as a timestamp-labeled picture for the agent to inspect directly. It distinguishes itself from siblings by contrasting with 'filmstrips' (whole-video overview) and noting it is for closer inspection. The two modes (times vs output_times) are clearly explained, making the purpose unambiguous.

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?

Provides explicit when-to-use guidance: 'before aiming anything and before disputing what a user saw, look.' It also states when not to use it for lip-reading or guessing words, directing to get_words/transcript instead. It differentiates from filmstrips and advises batching times into one call. This is comprehensive and actionable.

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.