Skip to main content
Glama

wait_for_video_translation

Wait for a submitted video translation to finish, then get the translated video and subtitle URLs. Polling adapts to progress changes, returning right away to avoid useless status checks.

Instructions

等待视频翻译任务完成。提交 translate_video 后就用它跟进,不要自己反复调 get_video_translation_status。上游只能轮询、无法推送,本工具有两个返回时机:进度一有变化就立刻返回,否则等满本轮的等待时长(不传 timeout 时由本工具自适应:10 秒起,进度一直不动就逐轮翻倍到 45 秒封顶,省掉那些什么都说不出来的空转往返)。视频任务通常要几分钟。返回里 msg 是念给用户听的那一行、agentNote 是给你的操作指令:要转述就转述 msg,agentNote 一个字都不要念出去。finished=false 表示仍在处理,照 agentNote 的要求办:进度有变化就把 msg 那行原样告诉用户,和上次完全一样时一个字都不要输出(连「继续等待」这类过场话也不要),直接再次调用本工具继续等待,任务不会因此中断。完成后返回里带 translatedVideoUrl / targetSubtitlesUrl,要把它们原样完整交给用户——问号后面的签名参数一字都不能改;有效期以返回的 expiresAt / downloadNote 为准,不要按经验说成一小时。描述产物时请原样照抄 msg 或 outputNote 里那句产出说明(例如「未配音(保留原声),已嵌入译文字幕」),不要凭之前传过的参数自己推断有没有配音。该任务做过字幕改写的话,返回里给的就是改写后那一版(带 rewriteOrderNo),outputNote 会注明,别再回头用改写前的链接。任务失败或被取消时返回 code=500 且 data.failed=true,reason 是原因——请先告诉用户,问过之后再决定是否重新提交,重提会再次扣费。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
localeNo把要念给用户听的那部分文案(任务状态、产出说明、进度行、失败原因、下载说明)输出成哪种语言。按用户当前说话的语言填,不确定就别传——不传取服务端 MCP_LOCALE,再没有就是 zh。
timeoutNo本次最多等待的秒数。**正常情况不要传**:不传时本工具自己掌握节奏——起步 10 秒,好让第一次进度尽快回到用户面前,之后进度每连着一轮没变就把等待翻一倍(10→20→40,上限 45 秒),进度一变又回到 10 秒。这么做是因为进度不动的那些轮次你什么都不该输出,可你每回来一次都是一整轮往返、上下文重发一遍,界面上还多一行空回合。传了本参数就按你给的秒数严格执行、不再自适应;传大值不会多打上游(轮询间隔是内部定的,与本参数无关),但超过你那端的工具调用超时会让本次调用直接报错——那是客户端超时,不是任务失败,任务还在跑,重新调本工具接着等即可。到点未完成会返回当前进度而非报错,可再次调用继续等待。
order_noYes视频翻译订单号,即 translate_video 返回的 videoTranslateOrderNo

Schema Changelog

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

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden — and it delivers thoroughly: adaptive polling cadence (10s start, doubling to 45s cap), the two return timings, the client-timeout-vs-task-failure distinction, task continuity across re-invocations, and the requirement to pass artifact URLs verbatim without altering signature parameters. It also discloses the rewritten-subtitle nuance and the cost implication of resubmission.

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?

A dense single paragraph where nearly every sentence carries a non-obvious operational rule (don't read agentNote aloud, don't emit filler lines, copy outputNote verbatim, don't infer dubbing from prior params). It is slightly overlong because the adaptive-timeout explanation duplicates what the timeout parameter's schema description already states.

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?

With no output schema, the description must substitute for return-value documentation, and it covers every return case: in-progress (msg/agentNote, finished=false), completion (translatedVideoUrl / targetSubtitlesUrl, expiresAt / downloadNote), rewritten subtitles (rewriteOrderNo, outputNote), and failure/cancel (code=500, data.failed=true, reason). Nothing an agent needs to invoke the tool correctly is left unspecified.

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 100%, and both locale and timeout already carry detailed schema descriptions — including the 10→20→40→45 adaptive timing that the description re-explains. The description adds marginal value by tying order_no to translate_video's videoTranslateOrderNo and advising that timeout normally be omitted, but the schema already handles parameter meaning.

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?

Opens with a specific verb+resource pairing ("等待视频翻译任务完成") and immediately defines the tool's role as the designated follow-up step after translate_video. It explicitly distinguishes itself from the sibling get_video_translation_status by telling agents not to poll that tool repeatedly.

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?

Provides an explicit routing rule: "提交 translate_video 后就用它跟进,不要自己反复调 get_video_translation_status". It also specifies when to re-invoke (keep calling while finished=false even if nothing is output) and when to defer to the user (tell the user the reason and ask before resubmitting after a failure, noting resubmission charges again).

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