Skip to main content
Glama
Sign In
Tapra MCP server

Tapra MCP server

Official
by tapra-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Transcribe video to subtitles

transcribe_video

Generates timed subtitle files (SRT, VTT, TXT) from videos by extracting audio, transcribing Derja, French, or English, and labeling speakers; optionally burns subtitles into an MP4.

Instructions

Make subtitles for a video: extracts the audio, transcribes Derja/French/English, and writes srt, vtt and txt in one go, timed for reading. Speakers are labelled and colored by default (no extra charge), with a speaker report and a clip of each voice; when there are several, ask the user whether to name them, then call name_speakers. Set burn_subtitles to also render a copy of the video with the subtitles drawn in. Needs ffmpeg. Costs money per minute.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input_path": "<input_path>"
    },
    "name": "transcribe_video"
  }
}

Input Schema

NameRequiredDescriptionDefault
promptNoNames or jargon likely to appear.
diarizeNoLabel and color each speaker (no extra charge). Set false for a single speaker.
formatsNoFiles to write. Default: all three (txt, srt, vtt). A .json with full timings is always written too.
languageNo
input_pathYesPath to the video file (mp4, mov, mkv, webm...).
output_dirNoFolder to write into. Defaults to a new folder in the output folder.
max_cost_tndNoRefuse to run if the estimated cost is above this many TND. Defaults to TAPRA_MAX_COST_TND when set.
subtitle_fontNoFont for burned subtitles. Must support Arabic; Tahoma and Segoe UI do (Arial drops the لا ligature).Tahoma
burn_subtitlesNoAlso render an MP4 with the subtitles drawn on the picture (speaker colors kept).
max_chars_per_subtitleNoLongest subtitle, in characters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the annotations (which only say non-readonly, open-world, non-destructive): it discloses the ffmpeg dependency, that each run costs money per minute, that files are written to disk in three formats plus a JSON with timings, and that a speaker report and voice clips are produced by default at no extra charge. These are exactly the facts an agent needs before spending money or prompting the user.

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?

Front-loaded with the core action and outputs, then conditions, then costs and dependencies. It is dense and slightly run-on in the speaker sentence, but every clause carries operational information (cost, dependency, follow-up call).

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 10-parameter, money-spending, file-writing tool with no output schema, the description covers dependencies, cost, side effects, and the follow-up flow. The one omission is where the resulting file paths are reported back, which matters for a tool that writes to disk.

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 90%, so the baseline is 3. The description reinforces a couple of behaviors the schema already documents (diarization labels and colors speakers by default; burn_subtitles renders a copy), but adds no new syntax, defaults, or constraints such as the max_chars_per_subtitle bounds or max_cost_tnd refusal behavior.

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 ('Make subtitles for a video'), enumerates the concrete outputs (srt, vtt, txt), and implicitly separates itself from siblings like speech_to_text and diarize_audio by covering the whole subtitle pipeline end to end. An agent can tell without opening the schema that this is the full-pipeline option rather than a raw transcription 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?

Gives clear conditional guidance: set burn_subtitles for a rendered copy, keep diarize on unless there is a single speaker, and after a multi-speaker run 'ask the user whether to name them, then call name_speakers'. That explicitly routes to a sibling tool. It does not, however, say when to prefer this over speech_to_text or diarize_audio, which is the remaining gap.

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

Deploy Server

Other Tools