Skip to main content
Glama

ffpipe — video conversion, probe & frames

extract_frames

Queue an asynchronous frame extraction - the tool to reach for when you need to SEE a video: fetches sourceUrl (or, with upload: true, waits for you to PUT the bytes to the returned uploadUrl) and extracts still frames as jpeg, webp or png. mode is REQUIRED and picks the sampling (all, every_nth, interval, keyframes, evenly_spaced, timestamps); there is no default because every candidate implies a rate you did not ask for. A finished job's resultUrl is a JSON MANIFEST: source display dimensions, fps, rotation, an echo of your parameters, frame_count, and one entry per frame with index, pts_time (seconds in the source) and its own download url on this gateway - fetch the manifest, then the frames you want. Need just ONE frame at a moment - a thumbnail, poster frame or screenshot at a given second? Use mode "timestamps" with a single value, e.g. timestamps=[5], format=jpeg; the result is still a one-entry manifest pointing at that image (if you would rather have the image bytes returned directly instead of via a manifest, tell us with leave_feedback - demand decides whether we add it). Up to 1000 frames per job; "all"/"interval" on a long source can exceed that and fail fast, so prefer interval, evenly_spaced or timestamps. Unreadable input, audio-only files and still images FAIL here (probe_media diagnoses those). Download within 24 hours. Paid: $0.01 USDC via x402 (base mainnet), or a frames-kind retryVoucher.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNoevery_nth only: keep every Nth DECODED frame (a frame index, not a time).
fpsNointerval only: frames per second, may be below 1 (0.5 = one frame every two seconds).
modeYesHow to pick frames (required): "all" every frame; "every_nth" every Nth decoded frame (needs n); "interval" a fixed rate in seconds (needs fps, may be below 1); "keyframes" keyframes only, cheap on long sources; "evenly_spaced" count samples across the window (needs count); "timestamps" one frame per given second (needs timestamps).
countNoevenly_spaced only: how many frames to spread across the window.
formatNoImage format of each frame, default jpeg (small and accepted by every vision API). png is lossless.
uploadNoSet true to upload the bytes yourself instead of giving a sourceUrl (exactly one of the two). The paid result then returns status awaiting_upload plus uploadUrl and uploadExpiresAt: HTTP PUT the raw bytes to uploadUrl before the deadline (201 -> queued). You are charged at acceptance; an abandoned upload window errors with no refund, while a pipeline failure after your upload earns a retryVoucher.
endTimeNoWindow end in seconds (0 or omitted = to the end); must exceed startTime.
qualityNoEncoder quality for jpeg/webp, default 85; ignored for png.
maxFramesNoCeiling on frames produced, default and hard limit 1000. A request whose sampling would exceed it fails before any decoding.
sourceUrlNohttps URL of the input media (<= 100 MiB). Fetched from datacenter IP ranges - prefer a presigned URL from storage you control; no IP literals, no localhost/.internal/.local. Provide EXACTLY ONE of sourceUrl or upload.
startTimeNoWindow start in seconds (default 0).
timestampsNotimestamps only: seconds into the source, one accurate frame each. Sorted for you.
retryVoucherNoRetry-voucher credential (`uuid.hmac`) from a failed paid job's status - pays for this call instead of x402. Single use, kind-matched.
maxOutputWidthNoFit box width applied to the source's DISPLAY dimensions: aspect preserved, never upscaled, oriented to the input. 0 = no limit on this axis.
maxOutputHeightNoFit box height, same rules as maxOutputWidth.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only provide basic hints (readOnlyHint=false, destructiveHint=false). The description goes far beyond, disclosing async behavior, upload flow with charging at acceptance, 24-hour download window, failure cases, and the manifest structure. It explains the retryVoucher mechanism and x402 payment. This is exemplary transparency.

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 long but well-structured, front-loading purpose and mode requirement, then covering output, edge cases, and payment. Every sentence adds value, though some redundancy exists (e.g., 'Up to 1000 frames' repeats maxFrames schema). It could be slightly trimmed but is efficiently organized.

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 (15 params, async, payment, no output schema), the description covers all essentials: input methods, output manifest, mode semantics, limits, failure modes, payment, and even a single-frame shortcut. Nothing an agent needs to invoke it correctly is missing.

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 covers 100% of parameters with descriptions, so baseline is 3. The description adds relational context: why mode is required ('no default because every candidate implies a rate you did not ask for'), how all/interval can exceed limits, and the upload parameter's detailed flow. It enriches understanding without repeating schema text.

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 the tool's purpose: 'Queue an asynchronous frame extraction - the tool to reach for when you need to SEE a video.' It specifies the verb, resource, and even the output format (manifest of frames). It distinguishes itself from siblings by explicitly positioning itself as the go-to for seeing video, contrasting with probe_media for diagnostics and convert_video for conversions.

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: 'the tool to reach for when you need to SEE a video.' It also covers when not to use it: 'Unreadable input, audio-only files and still images FAIL here (probe_media diagnoses those).' It advises on mode selection for long sources ('prefer interval, evenly_spaced or timestamps') and even suggests alternative modes for single frames. This is comprehensive.

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.

Resources