Skip to main content
Glama

Convert local video to GIF

abox_video_to_gif

Convert a local H.264 video time range into a bounded animated GIF with configurable frame rate, size, color count, dithering, and looping, and verify the output.

Instructions

Decode an admitted H.264 time range and write a bounded animated GIF using the website palette and encoding engines. Supports sampling rate, size, color count, dithering and looping. Verifies complete GIF streams, frame timing and quantized pixels. At most 200 frames and 16 million total frame pixels; color and timing are lossy, and sound is omitted. Requires a local browser.

Input Schema

NameRequiredDescriptionDefault
fpsNo
loopNo
colorsNo
ditherNo
max_sideNo
input_pathYesAbsolute local filesystem path. URLs and network shares are refused.
end_secondsNo
output_pathYesAbsolute local filesystem path. URLs and network shares are refused.
start_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.0

TDQS

A3.9/5.0
Behavior5/5

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

Goes well beyond the annotations (which only say it is a non-read-only, non-idempotent write). It discloses hard caps (200 frames, 16M pixels), lossiness of color and timing, sound omission, that output streams/frame timing/pixels are verified, and the 'Requires a local browser' environment dependency — all material behavioral facts an agent needs.

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?

Four dense sentences, front-loaded with the core action, with limits and caveats after. Efficient, though the phrasing 'admitted H.264' and 'website palette and encoding engines' is slightly opaque jargon that costs a little clarity.

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?

For a 9-param mutation tool with no output schema and no annotations detail, the description supplies limits, lossiness, verification, and environment requirements. It is nearly complete; only per-parameter range/default context is missing, though that lives in the schema.

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 coverage is only 22%, so the description needs to carry weight; it names five knobs (sampling rate, size, color count, dithering, looping) mapping to fps, max_side, colors, dither, loop. But start_seconds/end_seconds semantics beyond 'time range' and units/format details are left to the schema, and the 60s/1-50 ranges are not surfaced.

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?

States a specific verb+resource ('Decode ... and write a bounded animated GIF') and scopes it to a converted video time range, which distinguishes it from siblings like abox_gif_create or abox_video_reverse. However, it never names the near-neighbor abox_gif_create or explains the distinction, so an agent must infer it from the name alone.

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

Usage Guidelines3/5

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

The description implies usage through constraints ('Decode an admitted H.264 time range', 'Requires a local browser') but never states when to choose this over abox_gif_create or abox_gif_split, nor any exclusions. Usage is inferable but not guided.

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