Skip to main content
Glama
Sign In
immich-photo-manager

immich-photo-manager

by drolosoft
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Get video frames JSON

get_video_frames_json
Read-only

Extract frames from an Immich video as base64 JPEG with timestamps for HTML galleries and skills. Control size, count or interval; read-only.

Instructions

Frames of a video as base64 JPEG with timestamps, for HTML galleries and skills. Same parameters, gate (confirm above 12) and cap (120) as get_video_frames. Read-only.

Args:
    asset_id: The video asset's UUID.
    count: Frames evenly spaced over the segment (default 6). Ignored when interval > 0.
    size: 'thumbnail' (250px, ~1.6k tokens per frame) or 'preview' (1440px, ~6.4k). Default 'thumbnail'.
    start: Segment start in seconds (default 0).
    end: Segment end in seconds (0 = to the end).
    interval: One frame every N seconds instead of count (1 = one per second, the maximum granularity).
    confirm: Required (true) when more than 12 frames would be produced; ask the user first.

Returns: JSON {asset_id, duration, backend, count, frames:[{timestamp, data, type}]},
a confirmation plan {confirm_required, frames_planned, estimated_tokens, ...}, or {"error": ...}.

Input Schema

NameRequiredDescriptionDefault
endNo
sizeNothumbnail
countNo
startNo
confirmNo
asset_idYes
intervalNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare read-only, and the description goes well past them: it quantifies token cost per frame (~1.6k for thumbnail, ~6.4k for preview), states the 120-frame cap and the confirmation gate at >12, and discloses the three possible response shapes including a confirmation plan and an error object.

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 summary followed by a scannable args list and a returns line; nearly every sentence carries information. Minor waste in cross-referencing get_video_frames for params/gate/cap and then restating the gate and cap anyway.

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?

For a 7-parameter read-only extraction tool with an output schema, the definition covers inputs, cost, confirmation flow, and response variants. An agent could call it correctly and warn the user about token usage without consulting any other tool.

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?

Schema description coverage is 0%, so the description carries the full burden and does: every parameter gets meaning plus defaults, including the count-vs-interval override rule, the size enum values with actual pixel dimensions, start/end segment semantics (0 = to end), and confirm's trigger condition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names the resource and the exact output form: base64 JPEG frames with timestamps as JSON. It points at the sibling get_video_frames as the parameter-compatible counterpart, which implies the difference is the return encoding (JSON vs image content), but it never states that distinction outright, so an agent must infer it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'for HTML galleries and skills' gives a concrete use context, and the gate rule ('confirm above 12; ask the user first') tells the agent what to do before calling. What's missing is an explicit routing sentence such as 'use get_video_frames when you want inline images rather than base64 text'.

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

Deploy Server

Other Tools