Skip to main content
Glama

captions_burn

Burn SRT or ASS subtitles into video frames, permanently embedding captions in the picture for playback anywhere. Uses ffmpeg with libass and bundled fonts.

Instructions

Burn SRT/ASS subtitles into the picture. Needs an ffmpeg built with libass, plus fonts (both ship in the Docker image).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYes
subtitlesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It conveys that subtitles are visually embedded, but it does not disclose whether the input is modified in place, whether a new output file is created, or what the return value is. No destructive or read-only behavior is stated.

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?

Two short sentences, no filler. The main action is front-loaded and the prerequisite information is given in a second sentence. Every sentence earns its place.

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

Completeness2/5

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

This is a simple two-parameter tool, but with no output schema and no annotations, the description should at least explain the input/output contract. The agent is left to guess whether the result is written to file, returned, or rendered; the dependency note is useful but does not complete the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are no per-parameter descriptions, so the description must compensate. It adds the useful fact that subtitles can be SRT or ASS, but it never clarifies that 'input' refers to a video file, what formats or paths are expected, or where the burned output goes.

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 uses a specific verb and resource: 'Burn SRT/ASS subtitles into the picture.' It clearly identifies the action and format scope, and it is distinct from siblings like captions_write_srt or captions_transcribe. It could be stronger by naming a sibling, but the action is unambiguous.

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 second sentence gives environmental context for when the tool can be used (ffmpeg with libass, fonts available in the Docker image), but it does not specify when to choose this over alternatives or when not to use it. Usage is implied by the task description rather than explicitly stated.

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