Skip to main content
Glama

thumbnail

Generate a contact sheet by extracting evenly spaced frames from a video and tiling them into a grid image.

Instructions

Build a contact sheet: N evenly spaced frames tiled into a grid image.

Input Schema

NameRequiredDescriptionDefault
inputYesPath to the file (relative or absolute)
widthNoWidth of each tile in pixels
framesNo
outputYes
columnsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses the core behavior—sampling N evenly spaced frames and tiling them into a grid—but does not mention whether the input is expected to be video, whether frames are sampled across the full duration, how the output file is written or overwritten, or what errors may occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler. It efficiently communicates the core operation and result.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter tool with no annotations and no output schema, the description covers the central behavior but omits important context such as input media type, sampling semantics, output handling, and the meaning of key parameters. It is minimally adequate but incomplete for reliable invocation.

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 only 40%, and the description partially compensates by explaining that 'frames' means N evenly spaced frames and that output is a tiled grid image, implicitly covering 'columns.' It adds no meaning for 'width,' 'output,' or the allowed ranges and defaults, so it leaves notable parameter gaps.

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 description states a specific action and output: build a contact sheet by tiling N evenly spaced frames into a grid image. This is clear enough to distinguish it from siblings like extract_frame or resize, although it does not explicitly name alternatives.

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?

Usage is implied by the phrase 'contact sheet' and 'evenly spaced frames,' which suggests previewing multiple points in a media file. However, the description gives no explicit when-to-use or when-not-to-use guidance relative to extract_frame, resize, or other siblings.

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