Skip to main content
Glama

Get clip details

get_clip
Read-only

Read one clip: its elements (positions/sizes in canvas pixels), voiceover (text, voice, duration, voiceover_volume), background and transition. Pass render to also get a PNG of the frame.

ASK FOR WHAT YOU NEED. A full read is large — on a dense clip the per-word voiceover array and the element type_data blobs dominate it, and repeated full reads are the main way a long session runs out of context. select returns exactly the parts you name:

select: ['elements.x','elements.y','elements.width','elements.height'] → geometry only, to fix a layout select: ['elements.name','elements.start_time','elements.end_time'] → a timing pass select: ['words'] → word timings only, to sync visuals to narration select: ['elements.textdata','words'] → rewrite copy against the VO select: ['elements'] → whole element rows, no words select: [] → no JSON at all (pair with render for the PNG alone — smallest read) (omit select) → everything; fine for a first look, expensive to repeat

render is the other output, and it is separate from select: select shapes the JSON, render produces a PNG.

render: {} → the frame at t=0 render: { timestamp: 2.5 } → the frame 2.5s into the clip render: { save: true } → also uploads the PNG and returns presigned_url select: [], render: {} → the PNG alone, no JSON select: ['elements'], render: {} → element rows AND the frame

Omitting render renders nothing. timestamp and save live inside it because they only mean anything for a render — there is no way to ask for them without asking for the image.

element_ids is the other axis: it picks WHICH element rows come back, independently of select. Combine them for the leanest read — e.g. element_ids: ['el_9'], select: ['elements.x','elements.y'].

Element shape: universal wrapper fields (id, geo, name, x, y, width, height, start_time, end_time, rotation) plus type-specific data (textdata/shapedata/imagedata/videodata/zoomdata) plus an optional keyframes array when animated. Keyframes come back in the same flat wire shape add_elements takes — { timestamp, positionX?, positionY?, width?, height?, interpolation? } in canvas pixels — so you can round-trip read → edit → update_elements without reshaping.

Clip-level fields include transition (the current transition object — sibling of the update_clips transition arg; null if none) and voiceover_words (per-word timestamps; null on clips with no transcription).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
renderNoRender a PNG of the frame. Presence of this object IS the request to render — omit it and nothing is rendered. `{}` renders at t=0. Independent of `select`, which only shapes the JSON: pair `select: []` with `render: {}` for the PNG alone (smallest read). CHECKING YOUR WORK: pass a mid-clip `timestamp`, not the t=0 default — text and image elements have entry animations (a ~0.4s slide/fade by default), so at t=0 they have not arrived yet and a correct edit renders as an empty frame. Shapes have no entry animation and do show at t=0, which makes a t=0 render especially misleading: some elements appear and others don't.
selectNoAsk for exactly the JSON you want, GraphQL-style. Omit for everything; pass [] for none. Sections: 'elements' (whole element rows), 'words' (per-word VO timings). Rendering is `render`, not a value here. Per-key: 'elements.<key>' projects element rows to just those keys (id is always kept). Keys: name, geo, x, y, width, height, start_time, end_time, rotation, keyframes, textdata, shapedata, imagedata, videodata, zoomdata, codedata, parent_id. Examples: ['elements.x','elements.y','elements.width','elements.height'] to read geometry; ['elements.name','elements.start_time','elements.end_time'] for a timing pass; ['words'] to sync visuals to narration; [] with render:{} returns the PNG with no JSON (smallest read); ['elements.textdata','words'] to rewrite copy against the VO. Mixing 'elements' with 'elements.<key>' returns whole rows. Use element_ids to choose WHICH rows — that is independent of this.
clip_indexYesZero-based clip index
project_idYesThe project ID
element_idsNoWHICH element rows to return — all others are dropped. Independent of `select`, which chooses the sections/keys. Use it to re-inspect just what you added or updated; most add_elements/update_elements already echo the element's resolved layout, so often you don't need this at all.

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already declare `readOnlyHint: true` and `destructiveHint: false`, so the description doesn't need to restate safety. Instead, it adds enormous value by detailing the tool's expensive nature ('A full read is large'), the relationship between `select` and `render` as independent axes, and how keyframes and voiceover data are returned. This goes far beyond the annotations.

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 description is well-structured with clear sections and examples, making it highly informative. However, it is quite lengthy (over 600 words). While every sentence adds value, the sheer volume slightly impacts conciseness; a slightly tighter version could retain clarity while being more scannable.

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?

Given the tool's complexity (5 parameters, nested objects, no output schema), the description is remarkably complete. It covers what the tool reads, how to control the output via `select` and `element_ids`, how `render` works independently, and the structure of the returned elements. The only minor gap is no explicit mention of return format (e.g., JSON object), but the 'Read one clip' phrase implies a single response.

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

Parameters5/5

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

The input schema already has 100% coverage with descriptions for all 5 parameters. The description goes far beyond the schema by explaining the exact effect of combinations (e.g., `select: [], render: {}` yields only a PNG), providing concrete examples, and describing the returned data shapes (element wrapper fields, type-specific data). This adds immense meaning.

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 'Read one clip' with a specific verb and resource, and lists all the retrievable components (elements, voiceover, background, transition). It distinguishes itself by describing the `select` mechanism and the `render` parameter, which are unique to this tool and not present in sibling tools like `update_clips` or `update_elements`.

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?

The description provides explicit guidance on when to use this tool versus alternatives. It directly warns about the cost of 'repeated full reads' and explains how `select` can minimize context usage. It also hints at when to use sibling tools like `update_clips` (for transitions) and `update_elements` (for element edits) by describing the return format, enabling the agent to decide to read before editing.

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.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but there is notable overlap between remove_elements and remove_from_project(target='element'), which both remove elements from a clip. This duplication could cause an agent to misselect. Otherwise, tools like add_clips, add_elements, add_audio, and analyze_audio are well-differentiated.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., add_clips, create_project, get_clip, update_elements). There are no camelCase or mixed conventions. Even compound names like voiceover_batch and auto_sync fit the pattern. This makes the tool set predictable for an agent.

Tool Count2/5

With 40 tools, the set is significantly larger than the 3-15 range that typically earns its place. While the domain of video creation is broad, several tools seem redundant (remove_elements vs remove_from_project) or narrowly scoped (get_design_guide, get_element_schema), inflating the count. The number feels heavy for the apparent scope.

Completeness4/5

The tool surface covers most lifecycle operations: create, read, update, delete for projects, clips, elements, audio, articles, and clueprints. Minor gaps exist, such as no explicit tool to delete a voiceover (only mute via update_clips) and no folder management beyond listing. Overall, agents can accomplish full workflows with few workarounds.