Skip to main content
Glama

Transcribe and translate a video into editable subtitles

proofread

Transcribe a video and translate its transcript into target languages, returning editable .srt files and the source transcript so wording can be corrected before dubbing.

Instructions

Transcribe a video and translate its script into the target dubbing languages, returning one editable .srt per language plus the source-language transcript, so the text can be read and corrected BEFORE anything is dubbed. Nothing is spoken and no video is produced — this is the step before the dubbing tool. Send the edited files back as subtitles on the dubbing tool so the dub speaks exactly the approved wording.

⚠️ COST WARNING: This tool makes an API call to Sonilo which may incur charges, and you are billed PER LANGUAGE: video duration × the number of target languages at $0.001/sec, with a 10-second billing floor. A transcript-only request (no languages) counts as one language. Self-serve accounts get 2 free-trial runs on it. Only use when explicitly requested by the user.

Args: video_path (str, optional): Absolute local path, or relative to SONILO_MCP_BASE_PATH. Subject to the account's max upload size (typically 300 MB). video_url (str, optional): HTTPS URL to a video file. Must be https specifically — the backend fetches the source itself and rejects plain http. Either way: Maximum video duration is 300 seconds (5 minutes), and the video must have an audio track. languages (list, optional): Target language codes to translate the transcript into, e.g. ["ja", "zh_cn"]. These are the same codes the dubbing tool takes (see its languages argument for the list), so a proofread script can go straight into a dub. Omit it, or pass an empty list, for the source-language transcript alone. source_language (str, optional): Hint telling transcription which language to expect, one of the same codes — it helps on short, noisy or mixed-language audio. Omit it to have the language detected; either way the result reports the language the transcript is in. output_directory (str, optional): Where to save the results. Defaults to SONILO_MCP_BASE_PATH.

Exactly one of video_path and video_url must be provided.

Returns: One TextContent per saved file, named proofread-<first 8 chars of the task id>..srt — always including the detected source language as well as every requested target — then the detected source_language and cue_count, then one note per non-blocking warning (e.g. a cue whose text runs too fast to read). A warning never blocks the files. On timeout the error message includes the task_id — recover with get_sfx_task.

Input Schema

NameRequiredDescriptionDefault
languagesNo
video_urlNo
video_pathNo
source_languageNo
output_directoryNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.28.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (which only flag openWorldHint and non-read-only), the description discloses per-language billing math, a 10-second billing floor, free-trial limits, the 300s duration cap, the audio-track requirement, and that warnings never block file output. It also gives failure recovery (task_id in timeout errors, use get_sfx_task). This is unusually complete behavioral disclosure for a costly external API call.

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?

Purpose and the critical cost warning are front-loaded, and the Args/Returns structure is scannable. It is long, and the cost paragraph could be tightened, but nearly every sentence carries operational information an agent needs before spending money.

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

Completeness5/5

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

For a 5-param, zero-schema-coverage, paid external call, the description covers inputs, mutual exclusion, limits, cost, output file naming, and error recovery. Nothing an agent needs to invoke it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden — and it does: it explains each of the five params, including the https-only constraint on video_url, the 300 MB upload limit, that language codes match the dubbing tool's, the empty-list semantics for languages, and the source_language hint behavior. It also states the cross-parameter constraint (exactly one of video_path/video_url).

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?

The description states a specific verb and resource (transcribe a video, translate its script into target languages) and immediately delimits what it does NOT do ("Nothing is spoken and no video is produced"), which cleanly separates it from the `dubbing` sibling. An agent can distinguish it from every other sibling without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing: use this as the step BEFORE the dubbing tool, then feed the edited .srt files back as `subtitles` on `dubbing`. It also states the gating condition ("Only use when explicitly requested by the user") and the transcript-only case (omit languages). This is the full when/when-not/alternative set.

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