Skip to main content
Glama

translate_video

Submit a video translation job with optional voice cloning and subtitle styles. Uses a two-step confirmation flow to let users choose dubbing/subtitle combinations before final billing.

Instructions

提交视频翻译任务。⚠️ 本工具会真实扣减账户额度并计入调用次数,所以提交是一次两步调用,第一次一定不会提交: (1) 先用文件的真实时长调 calculate_video_translation_quota 试算,voice_role / subtitle_type 必须和接下来提交的值完全一致(对不上会被拒绝提交); (2) 带 voice_role 和 user_confirmed=true 调本工具,但不带 confirm_token——本工具此时不提交、不扣费,只返回 409、一段 data.userPrompt 和一张 data.options 菜单(配音 × 字幕的全部组合,每格带自己的额度和 confirmToken); (3) 把 data.userPrompt 原样发给用户,等他在菜单里挑一项或选放弃。做成什么样、扣多少额度是用户的决定,不要替他选,也不要只转述你自己那一组; (4) 用户挑了第几项,就用 data.options 里那一项的 voiceRole / subtitleType / confirmToken 三个值(必须同属一项,不能混、不能造菜单外的组合)重调一次,这一次才真的提交扣费;用户选放弃就到此为止。 (客户端支持 elicitation 时服务端会直接弹窗问用户,此时省去 3-4 步,一次调用即可。) voice_role 与 subtitle_type 决定这次翻译到底做什么:两者都关(voice_role 传 No 且 subtitle_type=0)等于既不配音也不嵌字幕,产出的视频和原片没有区别,但一样扣费——上游不拦这个组合,请在提交前自行拦下并问用户。返回 data.videoTranslateOrderNo 是后续所有查询用的订单号。同一份文件、同一目标语言 30 分钟内再次提交会被直接拒绝,除非带上 retry_of_order_no(上一单单号)和 retry_confirmed=true——任务失败后不要自己改个参数就重提,先把失败原因告诉用户、问过再说。限制:免费用户单个视频最长 10 分钟、每月累计 10 分钟、单文件 200MB、同时只能有 1 个进行中的任务(Pro 为 60 分钟/1024MB/2 个);这些是默认档位的值,账号实际的限额用 get_account_status 查,本工具提交前也会拿真实限额比一次,超了会直接拒绝(不提交、不扣费),到那时再重传剪短的文件就白传了一次。若 target_language 传 ar(阿拉伯语)且账号不是付费会员,上游要求人机验证 token,外部调用无法提供,会直接失败。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
localeNo把要念给用户听的那部分文案(任务状态、产出说明、进度行、失败原因、下载说明)输出成哪种语言。按用户当前说话的语言填,不确定就别传——不传取服务端 MCP_LOCALE,再没有就是 zh。
voice_roleYes配音开关,只有两个取值:No=不配音、只做字幕翻译(默认,与产品前端一致);clone=克隆原说话人音色做配音。clone 且 subtitle_type≠0 时**额度翻倍**——10 分钟视频 80 额度会变成 160,所以要不要配音必须先问用户,不要替他决定。服务端对本字段只校验非空,填其他值不会报错但会白扣额度,不要传这两个之外的值。
confirm_tokenNo确认码,来自本工具上一次调用返回的 data.options 里用户挑中的那一项。只有在把 data.userPrompt 原样给用户看过、用户明确选了某一项之后才带上它——带着它这一次就会真的扣费。首次调用不要传,也不要自己编一个。确认码自己记着它代表菜单里的哪一格:带上它时,配音和字幕按那一格定,你传的 voice_role / subtitle_type 会被忽略,所以不用去对,也别想用它换一格。一次性、15 分钟有效。
subtitle_typeNo0=不嵌入字幕, 1=翻译字幕(默认), 2=原始字幕, 3=翻译+原始字幕
user_confirmedYes用户已经看到试算额度、并明确选择了是否开启同声翻译(配音)后才传 true。为空或 false 时直接拒绝提交。注意它只是入场券:填了 true 也不会直接提交,还要走 confirm_token 这一步(或服务端弹窗)拿到用户本人的确认。
retry_confirmedNo重做时必填 true:表示已经把上一单的结果或失败原因告诉用户、并得到用户明确同意再扣一次费。不要自己填。
source_languageYes源语言代码
target_languageYes目标语言代码
video_file_nameYes视频文件名
video_task_paramNo完整的生成参数,覆盖 voice_role / subtitle_type 这两个快捷参数。配音:voiceRate 语速、volume 音量、pitch 音调(均为 +0% / +0Hz 这类字符串)、voiceAutorate 语音自动变速、videoAutorate 视频自动变速(默认都 true)。字幕样式:fontsize 字号(默认14)、fontname 字体、fontcolor 颜色(#RRGGBB)、fontbold 加粗、subtitlePosX 水平位置 5-95(50居中)、subtitlePosY 底边距 0-90、fontbordercolor 描边色、outline 描边宽 0-10(0关闭)、shadow 阴影 0-10(0关闭)、backgroundcolor 背景框色、borderStyle 1普通描边/3逐行矩形背景框。不传的字段走服务端默认值。注意服务端对这些字段一个都不校验,填了非法值不会报错、会照常扣费然后在生成阶段失败,不确定就别传。
retry_of_order_noNo重做时必填:上一单的 videoTranslateOrderNo。同一份文件、同一目标语言 30 分钟内再次提交会被拒绝,除非带上这个单号并把 retry_confirmed 置 true。
source_file_object_keyYes视频文件对象 key

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and succeeds completely: it warns that the tool '会真实扣减账户额度并计入调用次数' (really deducts quota and counts calls), that the both-off combination still charges despite producing an identical video, that the first call returns 409 with a userPrompt/options menu instead of submitting, that identical submissions within 30 minutes are rejected, and that video_task_param fields are not validated server-side so bad values charge then fail at generation.

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?

Every sentence earns its place — the cost warning is front-loaded as the first thing, followed by the protocol, the charge-despite-no-op warning, retry rules, and limits. However, the entire message is one dense wall of text with no paragraph breaks, numbered blocks, or bullets, which taxes readability for a 12-parameter, high-risk tool.

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?

Despite no output schema and no annotations, nothing an agent needs is missing: the two-step protocol, the 409 response shape (data.userPrompt, data.options with per-cell quota and confirmToken), the order number for later queries, default limits with a pointer to get_account_status, the 'ask the user, don't decide for them' instruction, and the Arabic edge-case failure. The description is fully self-sufficient for correct invocation.

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 coverage is 100%, but the description adds orchestration semantics the schema cannot: confirm_token overrides voice_role/subtitle_type ('你传的 voice_role / subtitle_type 会被忽略'), option-menu values must come from the same cell ('不能混、不能造菜单外的组合'), and retry_of_order_no requires retry_confirmed=true. It even preserves a precise naming distinction, using camelCase voiceRole/subtitleType/confirmToken when referring to menu items versus snake_case for API parameters.

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 opening line states a specific verb+resource ('提交视频翻译任务' — submit a video translation task) and the description then defines a precise submission protocol. It differentiates from siblings by naming calculate_video_translation_quota as the mandatory pre-step, get_account_status for real limits, and explaining that the returned data.videoTranslateOrderNo feeds all subsequent query tools.

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?

The description gives an explicit step-by-step when-to-call protocol: first call without confirm_token never submits, second call with confirm_token actually commits. It states exclusions and prerequisites — Arabic (ar) with a non-paid account will fail due to human-verification token requirements, real limits must be checked via get_account_status, and retries require asking the user first rather than silently changing parameters.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhang452064326/belindoc-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server