Skip to main content
Glama

Narrate

narrate
Destructive

Add offline voiceover to a video by speaking each line at its timestamp or marker, and generate a matching SRT file.

Instructions

Offline voiceover with the built-in Windows voices: speaks each line at its time or marker over the audio, plus an SRT.

Input Schema

NameRequiredDescriptionDefault
duckNoDuck the original audio (default true).
rateNoDefault 1.
linesYes
videoYesPath to the video.
voiceNoVoice name or part (doctor lists them).
outputNoOptional output path. Defaults under SCREENCAST_HOME/edits.
overwriteNoAllow replacing an existing file at the output path (default false).

Output Schema

NameRequiredDescriptionDefault
outputPathYesPath of the file written.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.47.0

TDQS

A3.7/5.0
Behavior3/5

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

The description adds useful context beyond the annotations by disclosing that narration uses built-in Windows voices, works offline, and also produces an SRT. It does not mention the destructive/overwrite behavior signaled by destructiveHint=true or the overwrite default, leaving those details to the schema and annotations.

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 single sentence is front-loaded with the core purpose and contains no filler. Every phrase contributes to describing the voiceover mechanism, timing behavior, and SRT output.

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?

Given the rich schema coverage, annotations, and presence of an output schema, the description is mostly complete for an agent to understand the tool's role. It does not mention the required video path or overwrite implications, but those are adequately covered by the schema and annotations.

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 coverage is high at 86%, so the baseline is 3, but the description adds meaningful semantics for the nested lines array by explaining that each line is spoken at its time or marker. It also clarifies the audio-overlay and SRT output behavior, though it does not discuss rate, duck, or overwrite parameters.

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 gives a specific verb and resource: it produces an offline voiceover using built-in Windows voices and speaks each line at its time or marker. This clearly separates it from sibling audio tools like music_bed, transcribe, or burn_subtitles, though 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 'offline voiceover' and the explanation that lines are spoken at timestamps or markers. However, the description does not state when to use this tool instead of related siblings such as music_bed, transcribe, or burn_subtitles, nor does it give any exclusion conditions.

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