Skip to main content
Glama

wait_for_translation

Wait for a translation task to complete, return progress updates as they occur, and provide signed download URLs when finished.

Instructions

等待翻译任务完成。上游只能轮询、无法推送,本工具有两个返回时机:进度一有变化就立刻返回,否则等满本轮的等待时长(不传 timeout 时由本工具自适应:10 秒起,进度一直不动就逐轮翻倍到 45 秒封顶,省掉那些什么都说不出来的空转往返)。返回 finished=true 时附带 downloadUrl(纯译文,CloudFront)与 downloadUrlCN(同一文件的国内兜底线路),其他版式用 get_document_translation_result 取。这两条链接带签名,转述时必须把问号后面的参数一起原样给全,截断会 403。返回里 msg 是念给用户听的那一行、agentNote 是给你的操作指令:要转述就转述 msg,agentNote 一个字都不要念出去。finished=false 表示仍在处理,照 agentNote 的要求办:进度有变化就把 msg 那行原样告诉用户,和上次完全一样时一个字都不要输出,直接再次调用本工具继续等待,任务不会因此中断。若任务被服务端取消或失败,返回 code=500 且 data.failed=true,reason 是原因(如 BACKEND_CANCEL)——请先把原因告诉用户,问过用户之后再决定是否用相同参数重试 translate_document,文件不需要重新上传。

Input Schema

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

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?

With no annotations provided, the description carries the full burden and delivers extensively: two return timings, adaptive timeout ramp (10s→20s→40s, 45s cap), progress-change resets, signed URL query-parameter fragility (truncation causes 403), the msg-vs-agentNote split with the rule to never read agentNote aloud, and the failure envelope (code=500, data.failed=true, reason like BACKEND_CANCEL). This is unusually complete behavioral disclosure for a polling utility.

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?

The description is long, but the tool's behavioral surface genuinely demands it — every sentence carries operational weight (return timing, URL signatures, message-role rules, failure handling). Core purpose is front-loaded. It loses a point for being one dense run-on paragraph with no separation between the polling, success, in-progress, and failure sections, which makes the guidance harder to scan.

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?

Given no output schema and no annotations, the description covers every state the agent will encounter: success (finished=true with both signed URLs), still-processing (finished=false with exact output rules), failure (code=500/reason with retry protocol), and timeout behavior. The only minor omission is the exact shape of agentNote, but its role and usage are specified well enough for correct invocation.

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%, so baseline is 3. The schema already documents timeout's adaptive mechanism, the locale fallback chain, and order_no's meaning. The tool description restates the adaptive timeout in condensed form but adds no genuinely new parameter semantics beyond what the schema provides — it neither needs to nor does it.

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 ('等待翻译任务完成' — wait for translation task completion), and immediately differentiates from siblings by naming get_document_translation_result as the alternate for other formats. The polling-vs-push constraint further anchors what this tool uniquely does among the 23 sibling 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?

Provides explicit actionable guidance for every branch: when finished=false and progress is unchanged, call again with no output; when failed, tell the user the reason and ask before retrying translate_document. Names the alternative tool (get_document_translation_result) explicitly and states the client-timeout-is-not-task-failure principle, so the agent knows exactly when to keep polling versus switch tools.

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