Skip to main content
Glama

FilmLab

by com.thefilmradar
OverviewDiscussionsAdmin

Frames at Seconds

lab_bilder
Idempotent

See a clip at EXACT seconds: up to 12 frames, in the order you list them, tiled into one image and shown. Use it to check what is on screen where you plan a cut, whether a motion has ended, or whether a face drifted between two moments — lab_contact_sheet spreads frames evenly and cannot answer 'what is at 3.2 s'. A second past the clip's end is rejected by name, not clamped. Works on generated clips (video_id) AND on your own uploaded footage (project_id + asset_key from lab_add_media) — look at it before you cut it. Free (no credits).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
previewNoShow the image inline (default true)
sekundenYesSeconds into the clip, e.g. [0.5, 3.2, 3.24]. Order is kept: left to right, then the next row (4 per row)
video_idNoGenerated video id (from lab_animate/lab_job_status) — positive integer as string. Give this OR asset_key
asset_keyNoStorage key of uploaded footage (from lab_add_media / lab_list_assets). Needs project_id
project_idNoProject the asset_key belongs to — required with asset_key
kachel_breiteNoWidth of one frame in px (default 480)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed4 schema fields changed
    • addedInput schema / properties / asset_key
      Added value: +{
+  "description": "Storage key of uploaded footage (from lab_add_media / lab_list_assets). Needs project_id",
+  "type": "string"
+}
    • addedInput schema / properties / project_id
      Added value: +{
+  "description": "Project the asset_key belongs to — required with asset_key",
+  "type": "string"
+}
    • changedInput schema / properties / video_id / description
      Previous value: -"Generated video id (from lab_animate/lab_job_status) — positive integer as string"New value: +"Generated video id (from lab_animate/lab_job_status) — positive integer as string. Give this OR asset_key"
    • changedInput schema / required
      Previous value: -[
-  "video_id",
-  "sekunden"
-]New value: +[
+  "sekunden"
+]
  3. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations cover idempotency and non-destructiveness, but the description adds real behavior the annotations cannot: out-of-range seconds are rejected by name rather than clamped, the call is free (no credits), and it accepts two different source modes (generated video_id vs uploaded project_id+asset_key). The readOnlyHint=false is not contradicted by the text, since the tool does produce a new tiled image artifact, though the description never explains that distinction.

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-loaded with the core action and capped at a handful of dense sentences that each carry information. Slightly bloated by the em-dash asides and the marketing-flavored closer ('look at it before you cut it'), but nothing is redundant.

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?

No output schema exists, and the description fully specifies the return shape (one tiled image shown inline), plus error behavior and cost. For a six-parameter, dual-source frame-extraction tool this is complete enough to call correctly.

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 100%, so the baseline is 3; the schema already documents ordering, row layout, the 12-item cap, and the source-id pairs. The description mostly restates these ('up to 12 frames, in the order you list them') and only adds the provenance pointer for asset_key/video_id, which is marginal over the schema.

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+resource ('See a clip at EXACT seconds'), the output form (up to 12 frames tiled into one image), and the exact scope that separates it from the nearest sibling by name. An agent can tell this apart from lab_contact_sheet 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 concrete when-to-use triggers (checking what is on screen before a cut, whether motion has ended, whether a face drifted) and an explicit when-not with the named alternative: lab_contact_sheet spreads frames evenly and cannot answer 'what is at 3.2 s'. It also states the workflow ordering ('look at it before you cut it').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All FilmLab toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources