Tapra MCP server

Official

Overview Schema Source Related Servers Discussions Admin

Create a voiceover

create_voiceover

Converts a script or subtitle file into a timed voiceover track with per-line audio clips and a manifest for video editing, and can optionally add the narration to a video.

Instructions

Turn a script or a subtitle file into one narration track for video work. Each line is spoken with the same Tapra voice (amal = Mature woman. Warm, grounded, everyday Tunisian.; salma = Younger woman. Lighter and brighter, conversational.; salah = Man with a big, sharp (aigu) voice that carries. Strong presence.; fahmi = Middle-aged man. Normal, natural male voice.; leo = Young man. Light and energetic. The default Tapra voice.; voice cloning is not available) and placed on a timeline: at its subtitle time (from srt_path) or one after another (from script or lines). Lines may use effect tags ([euh] breathy hesitation; [aaa] long filler while thinking; [hmm] closed-mouth "mmm"; [ahem] clears the throat; [ouf] tired sigh; [breath] out-breath, "haah"; [stutter] repeats the first sound of the next word; put it right before that word). Writes a folder with the voiceover track (wav or another format), one WAV clip per line, and manifest.json (text + start/end per clip) that video generation tools can follow. Optionally lays the voiceover onto a video. Reports progress per line. Costs money per character.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_voiceover"
  }
}

Input Schema

Name	Required	Description	Default
`lines`	No	Narration already split into lines, spoken in order.
`speed`	No	Speaking rate, 0.7-1.3. Default 1.0.
`voice`	No	Tapra voice: amal = Mature woman. Warm, grounded, everyday Tunisian.; salma = Younger woman. Lighter and brighter, conversational.; salah = Man with a big, sharp (aigu) voice that carries. Strong presence.; fahmi = Middle-aged man. Normal, natural male voice.; leo = Young man. Light and energetic. The default Tapra voice.. Voice cloning is not available.	leo
`format`	No	Audio format: wav (default, lossless), mp3_<rate>_<kbps>, pcm_<rate> (16-bit WAV), ulaw_8000 / alaw_8000 (telephony), opus_48000_<kbps> (Ogg Opus). mp3, opus, ulaw and alaw need ffmpeg.	wav
`script`	No	Plain narration text. Split into lines at line breaks and long sentences.
`timing`	No	With srt_path: "fit" stretches or squeezes each line to its subtitle slot; "natural" keeps natural length.	fit
`quality`	No	"full" = best quality; "flash" = same voices, about 5x faster and cheaper.	full
`srt_path`	No	SRT/VTT file: each subtitle is spoken at its own time (dubbing).
`output_dir`	No	Folder to write into. Defaults to a new folder in the output folder.
`video_path`	No	Also produce a copy of this video with the voiceover as its sound.
`gap_seconds`	No	Pause between lines when there are no timings.
`max_cost_tnd`	No	Refuse to run if the estimated cost is above this many TND. Defaults to TAPRA_MAX_COST_TND when set.
`convert_arabizi`	No	Convert Arabizi (e.g. "3aslema") to Arabic script before speaking, as Voice Studio does.
`original_audio_volume`	No	With video_path: keep the original sound under the voiceover at this volume (0 = replace it).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Oct 30, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only declare a non-idempotent, open-world, non-destructive write; the description adds the substantive behavior an agent would otherwise miss: money is charged per character, a cost guard exists, progress is reported per line, and the write produces a folder with a track plus per-line WAVs and manifest.json. It does not say what happens to a pre-existing output_dir, which is the one behavioral gap left for a mutation tool.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is essentially one enormous sentence stitched together with semicolon-laden parentheticals, and a large chunk restates the voice enum and format noise already in the schema. It is readable but far longer than needed for the value delivered.

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?

With 14 optional parameters and no output schema, the description usefully describes what lands on disk (voiceover track, per-line WAV clips, manifest.json with text and start/end) and that a video copy can be produced, which is exactly what an agent needs to chain into video generation. Remaining params like speed and convert_arabizi are left entirely to the schema, which is acceptable at 100% coverage.

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 100%, so the baseline is 3, but the description genuinely adds information absent from the schema: the effect-tag vocabulary ([euh], [aaa], [stutter], and where to place a tag) and the distinction that timing only applies with srt_path and gap_seconds only without timings. The voice catalog is duplicated verbatim from the enum and adds nothing.

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

Purpose5/5

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

States a specific verb and resource ('Turn a script or a subtitle file into one narration track for video work') and makes the scope distinguishable from the plain text_to_speech sibling by emphasizing timeline placement, per-line clips, and optional video layering. An agent can tell immediately this is the multi-line narration assembler, not a single-utterance TTS call.

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?

The description makes the input-mode routing clear: use srt_path when subtitles carry timing ('dubbing'), or script/lines for sequential placement, and 'video work' frames the use case. It does not explicitly say when to prefer text_to_speech or translate over this tool, so the exclusion half of the guidance is missing.

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

Deploy Server