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

With no annotations provided, the description carries the full behavioral burden and handles it well: it clearly states the operation is non-charging ('不扣费'), explains the pricing basis (video duration), and corrects the misconception that rewriting is free. It does not discuss auth or side effects, but the non-destructive nature is explicitly disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three tight sentences with no filler. It front-loads the core purpose, adds the no-charge caveat, gives pricing context, and ends with a practical usage note. Every sentence earns its place.

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

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

The tool has one required parameter, full schema coverage, and no output schema. The description explains the quota semantics and even tells the agent to report the number to the user, which partially covers the return value. Since there is no output schema, a bit more explicit detail about the returned format could help, but the context is adequate for a simple calculator.

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

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

Schema description coverage is 100%, so both parameters are already fully documented. The description adds no new parameter-level detail, but it does supply useful pricing context that helps the agent understand why order_no matters. This matches the baseline of 3 when the schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it calculates quota for regenerating a video with corrected subtitles, and explicitly notes it does not charge ('不扣费'). It also distinguishes this from first-time translation by explaining rewrite is a new translation task priced identically, not a free rework.

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

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

The description gives clear context for when to use the tool: before proofreading/correcting subtitles, ask this first and relay the number to the user. It implies this is the right tool for rewrite-cost questions rather than initial translation quota, though it does not explicitly name sibling tools or state when not to use it.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it states '不扣费' (no charge), warns that the server can't verify video_duration, notes that invalid voice_role values '不会报错但会白扣额度', and explains the consequences of warnings (server rejection).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded: the first sentence states purpose and side effects, followed by billing rules and warnings. The ffprobe command, concrete examples, and repeated doubling warning each serve a necessary safety purpose, so no sentence feels wasted.

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

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

The description thoroughly covers input semantics, billing rules, and warning fields, but because there is no output schema, it does not name the normal return field containing the calculated quota. It mentions limitWarning and quotaWarning explicitly, so the gap is minor but real for an agent needing to read the primary result.

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

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

Every parameter has rich semantic detail beyond the schema: voice_role enumerates valid values and the doubling rule, subtitle_type lists all mappings, and video_duration specifies milliseconds, gives an ffprobe command, and explicitly forbids file-size estimation. Schema coverage is 100% and the description adds substantial operational value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens by stating the tool's exact function: '试算视频翻译要消耗多少额度，不扣费' (calculate video translation quota, no deduction). It also explicitly ties it to the workflow before '提交 translate_video 前应当先调这个', clearly distinguishing it from siblings like calculate_rewrite_quota.

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

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

It gives explicit when-to-use guidance: call before submitting translate_video and tell the user the result. It also provides a concrete condition for not calling ('读不到真实时长就别试算') and instructs how to handle limitWarning/quotaWarning before proceeding.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses a specific error code (31008) and the task-state precondition, which adds meaningful behavioral context beyond the tool name and schema. It could also mention irreversibility or success response, but the key edge case is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences: the first states the core purpose, the second adds the critical usage constraint and error behavior. No filler or redundant repetition of schema information.

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

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

The description covers the essential context: purpose, the eligible task status, and the error returned for ineligible tasks. Since there is no output schema, a brief mention of the success return format would improve completeness, but the core information needed to invoke the tool correctly is present.

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

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

The schema already provides 100% coverage for the single parameter, describing order_no as the video translation task order number. The tool description adds no additional parameter-level detail beyond what the schema states, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (cancel) and resource (video translation task), and the constraint (only status=0 tasks) distinguishes it from video creation/status/rewrite sibling tools. An agent can immediately identify this as the cancellation operation.

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

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

The description explicitly states when the tool can be used (only status=0 tasks) and what happens if misused (error 31008 for started tasks). It does not explicitly name a sibling alternative for checking status, but the precondition is clear enough to guide usage.

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

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

With no annotations provided, the description carries the full burden, and it excels. It discloses latency expectations ('大文件可能要等十几秒到一分钟'), explains that results are cached and reused, clarifies that the tool never turns off OCR explicitly enabled by others, and describes the code=500 case as non-fatal. It also explains quota implications and the double-deck PDF flattening flow.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense and every sentence serves a purpose. It is front-loaded with the core purpose, then moves through call timing, format restrictions, return interpretation, downstream behavior, latency, and error handling. No filler or redundancy is present.

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

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

There is no output schema, so the description correctly explains isOcr, isDoubleDeck, msg, and code=500. It also covers the complete workflow: when to call it, how to act on each result, whether to propagate OCR settings, and how to handle delays and errors. Nothing essential is missing for an agent to invoke this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions file_object_key contextually as the object key obtained from upload, and file_name is already described in the schema as an optional readable label. The description adds no additional parameter-level semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: '判断一个已经传上去的 PDF 是不是扫描件（图片版）' — it clearly states the tool's function of detecting whether an uploaded PDF is a scanned/image document. It also distinguishes itself from other file-handling tools by explicitly noting that only PDFs need this check.

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

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

The description gives precise when-to-use guidance: call it after the upload returns HTTP 200 and before submitting translation. It explicitly states that non-PDF formats do not need this call, and it explains how the result feeds into translate_document, including that no is_ocr value needs to be passed back. Alternatives and follow-up actions are fully covered.

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

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

With no annotations, the description carries the full burden and excels: it clarifies that quota.wallet already includes free consumption, freeUsed/freeTotal are not balances, OCR numbers sync with wallet, limits are enforced server-side, and error code 500 is returned when not found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Though long, every sentence adds critical caveats and correct misconceptions. It flows from purpose to balance semantics, limits, and error handling—front-loaded and well structured.

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

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

No output schema or annotations exist, yet the description thoroughly explains return fields, their meanings, hard limits, a hidden limitation, and failure behavior. Nothing essential for correct invocation and interpretation is missing.

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

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

Schema coverage is 100% with a clear description of the refresh param. The description adds no additional param info, but baseline 3 is appropriate per high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: '查询账户的可用额度、会员档位和各项限额' (query account's available credit, membership tier, and limits). This clearly distinguishes it from sibling translation/document tools.

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

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

It explicitly states when to use it: '要报余额、要判断「够不够翻这一单」时用它', and warns against inferring balance from prior order deductions. However, it does not name alternative sibling tools (e.g., calculate_video_translation_quota) for related cost checks.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but '通过批次号查询翻译任务' merely implies a read-only lookup. It does not mention response shape, polling semantics, error behavior, or any side effects, so an agent cannot predict behavior beyond the basic verb.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence with no filler and the key lookup criterion is front-loaded. Its brevity sacrifices informational depth, but it is clean, scannable, and contains only meaningful words.

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

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

Despite the simple one-parameter schema, there is no output schema and no description of what the tool returns. Sibling tools with different purposes (status, result, list) make this ambiguity material, so the description is not complete enough for an agent to reliably select and interpret the call.

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

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

Schema coverage is 100% because batch_no is already documented as '批次号'. The description repeats that concept in '通过批次号' without adding format, example values, or clarification of where the batch number comes from, so it adds no real value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('查询' / query), the target resource ('翻译任务' / translation task), and the lookup key ('批次号' / batch number), so the tool's basic purpose is clear. However, it does not differentiate itself from sibling tools such as get_document_translation_status or get_document_translation_result, which also query translation-related information.

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

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

There is no guidance about when to use this tool instead of related siblings like get_document_translation_status, get_document_translation_result, or list_document_translations. The one-line description provides no usage context, exclusions, or alternative routing.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses non-obvious behavior: comparison versions are synthesized on demand and not prefetched, slowness on first fetch is normal, URLs use CloudFront with url2 as domestic fallback, and query-string signature parameters must be preserved verbatim or the link fails with 403. This is far beyond a bare statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then packs related warnings and URL-handling rules into a dense but purposeful paragraph. There is no filler or duplicated schema content, and each clause adds operational value.

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

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

With no output schema and no annotations, the description goes beyond the basics by explaining the response's two link fields, the signing requirement, the 403 failure mode, and the latency behavior. It also embeds parameter constraints and user-facing instructions, leaving no major gap for an agent to call the tool correctly.

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

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

The input schema already documents all four parameters (100% coverage), so the baseline is 3; the description nevertheless adds operational meaning for url_type (including the warning '要译文不要传 1' and the PDF/EPUB constraints) and explains the meaning of url/url2 in the response. It doesn't need to repeat locale/order_no/is_watermark because the schema covers them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with the concrete action '获取文档翻译结果下载链接' (get document translation result download link), naming both the verb and the exact resource. By describing download-link retrieval rather than status, it clearly separates it from sibling tools like get_document_translation_status and list_document_translations.

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

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

Gives explicit when-to-use conditions for each url_type and states when not to act: '对照版是取的时候现合成的，第一次取可能要多等一会儿……别当成失败去重试，更不要因此改回纯译文' and '用户点名要哪一版再来调'. It does not explicitly name alternative sibling tools, so it falls just short of a full when/when-not comparison.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses a non-obvious behavior: the response contains no download URL, and the details returned are watermarked. It also clarifies that the watermark toggle only affects get_document_translation_result, preventing a likely misuse. It does not describe status values or error behavior, but the core behavioral trap is addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The purpose is front-loaded and the critical caveat about downloads and watermarks is stated immediately after, making the most important operational detail highly visible.

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

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

For a status-query tool with no output schema and no annotations, the description covers the essential purpose and the most likely source of confusion (downloads/watermarks). It does not enumerate possible status values or polling behavior, but for a simple status check this is a minor gap rather than a blocking one.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (locale and order_no) in sufficient detail. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('查询文档翻译任务状态' - query document translation task status). It clearly distinguishes itself from the sibling get_document_translation_result by stating that this tool does not return download addresses and that the watermark switch only affects the result tool.

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

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

The description gives explicit routing guidance: if the user needs to download the translated document, always use get_document_translation_result. It also explains why (this tool returns only the upstream default watermarked version), making the alternative selection unambiguous.

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

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

With no annotations provided, the description fully carries the behavioral transparency burden. It explains the return data structure (list of objects), the meaning of each field (model, coefficient, locked), and the billing implications (coefficient 3 consumes 3x quota). It stops short of discussing potential errors or authorization details, but for a read-only list tool this is strong context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, information-dense, and every sentence earns its place. It front-loads the purpose, then gives workflow ordering, return field semantics, billing behavior, and a warning about locked models—all without redundancy.

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

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

Given the tool has no parameters and no output schema, the description compensates fully by explaining the return data structure and field meanings. It also provides enough workflow context (call before translate_document, let user choose) for the agent to use the tool effectively. No critical missing information.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to elaborate on parameters since none exist, and the schema already reflects that. No additional parameter-level context is required or possible.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('获取') and resource ('翻译模型列表'), and further distinguishes itself by explicitly tying its usage to the translate_document workflow. It is clearly separated from sibling tools like get_supported_languages because it is about model selection for translation, not just languages.

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

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

The description gives explicit usage guidance: call this tool before translate_document, have the user pick a model, relay the coefficient (billing multiplier), and avoid locked models for submission. This covers when to use, how to present results, and what not to do, leaving no ambiguity for the agent.

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

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. It adds useful context — the return mapping (language code -> display name) and the orchestration role — but does not disclose the exact response structure, error behavior, or explicitly confirm a read-only/no-side-effect profile. Adequate but with a real gap given zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences: the first names the function and return content, the second gives usage sequencing. Every sentence earns its place, and the most important information is front-loaded.

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

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

Complete for a simple list tool with one optional parameter: it states what is returned and when to call it. Since there is no output schema, the return-value hint ('语言码 -> 显示名') partially compensates, though the exact response shape remains unspecified. A minor but non-critical gap.

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

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

Schema description coverage is 100%, with display_locale fully documented in the schema (default zh, allowed values listed). The description adds no new parameter semantics beyond what the schema already provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('获取支持的语言列表') and specifies the return content (language code -> display name). This clearly differentiates it from sibling list tools like get_model_list, so an agent can select it correctly 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.

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

The description explicitly instructs calling this tool before translate_document so the user can choose source and target languages. It gives clear sequencing context and purpose, but doesn't mention whether it also applies to video translation workflows (translate_video) or name any exclusions, so it falls short of full when/when-not guidance.

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

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

There are no annotations, so the description carries the full behavioral burden. It discloses the non-obvious SSE first-frame behavior, defines all status codes, and explains what happens after success. This is strong transparency for a polling endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three dense sentences with no filler: purpose, status semantics, and downstream action. Each sentence earns its place and the most important information is front-loaded.

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

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

Even without an output schema, the description tells the agent exactly what statuses to expect, how the upstream behaves, and where to retrieve the final rewrite artifacts. For a one-parameter status endpoint, this is complete enough to invoke correctly.

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

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

Schema description coverage is 100%, and the schema already documents order_no as '改写任务订单号'. The description references order-related context but does not add new parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence clearly identifies a specific verb and resource: querying the progress of a subtitle rewrite task. It differentiates itself from sibling tools by focusing on rewrite tasks rather than translation tasks, and the downstream references to get_video_translation_status make the distinction explicit.

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

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

The description explicitly tells the agent to use this tool for rewrite-task progress, and after success to switch to wait_for_video_translation or get_video_translation_status with the original video order number. This provides clear when-to-use and next-step alternatives without leaving the decision to inference.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does this well by revealing the error code 31008, the rewrite-record behavior, and the expiration of returned URLs. This is meaningful context beyond a simple retrieval statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, each earning its place: purpose, status precondition, rewrite behavior, and expiration caveat. No fluff or redundancy.

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

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

For a one-parameter retrieval tool with no output schema, the description covers purpose, preconditions, error handling, rewrite handling, and URL expiration. An agent has the necessary information to call it correctly and interpret expected responses.

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

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

The schema already provides 100% coverage for order_no with a clear description. The tool description adds contextual constraints but no additional parameter-level meaning, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: obtaining the original and translated subtitle download addresses for a video. It clearly distinguishes itself from sibling status/rewrite tools by emphasizing download addresses and the rewrite-record behavior.

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

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

Explicitly specifies the precondition that task status must be 2, and describes the failure mode when this condition is not met. Although it doesn't explicitly name sibling alternatives, the status precondition gives clear guidance on when to call this tool.

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

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

The description transparently discloses behavior beyond the minimal annotation: it returns immediately after the first SSE frame (does not hang), defines all status codes (0-4) with a warning not to confuse with document translation codes, explains step meanings, and recommends a polling interval. This is substantial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise but includes essential contextual warnings and usage advice. It is front-loaded with the core purpose and flows logically through behavior, status codes, steps, and polling recommendation, making it well-structured.

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

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

The description covers the tool's purpose, non-blocking behavior, status code meanings, step meanings, polling advice, and locale guidance. It lacks an explicit mention of the response format, but the status and step explanations provide sufficient context for a status query tool.

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

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

The input schema already provides comprehensive descriptions for both parameters, especially locale (purpose, fallback to MCP_LOCALE, default zh). The tool description adds no additional parameter clarification, so the baseline for high schema coverage applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool queries the status of a single video translation task ('查询单个视频翻译任务的状态'), clearly specifying the action and resource. This distinguishes it from sibling tools like get_video_rewrite_status or get_document_translation_status.

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

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

The description advises polling every 10-30 seconds and warns about the status code difference from document translation, giving practical guidance. It does not explicitly mention alternatives like wait_for_video_translation, but the non-hanging behavior ('不会挂住') implicitly suggests this tool is suitable for polling.

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

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

With no annotations provided, the description carries the full burden. It transparently states that download addresses are not included and points to the alternative tool that handles is_watermark and signed links, giving clear behavioral expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the primary purpose and immediately followed by a clear limitation and pointer. Every word adds value.

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

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

For a simple list-query tool, the description covers its function, its limitation (no download links), and directs users to the correct alternative. Combined with the schema's parameter descriptions, an agent has all necessary context to invoke it correctly.

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

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

The input schema already provides descriptions for all four parameters (100% coverage), so the description itself adds no additional parameter semantics. It neither enhances nor contradicts the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose (query a list of document translation tasks) and explicitly distinguishes it from the sibling tool for downloading results, so an agent can immediately understand its role.

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

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

The description explicitly says when to use this tool (for finding order numbers and statuses) and when not to (for downloading, use get_document_translation_result instead). This leaves no ambiguity about selection.

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

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

With no annotations, the description carries the full burden and does it well: it discloses the 15-day retention window, the intentional absence of download links, the payload-size rationale, and the fact that even if links existed they could expire. It does not explicitly say the operation is read-only or describe pagination defaults, but the key non-obvious behaviors are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: purpose, status mapping, no-download-links rationale, and the alternative routing are all stated compactly. The most important scoping constraints are front-loaded, and the explanation of why links are omitted is concise and not redundant.

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

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 the essential return semantics: what the list is for, what it returns at a high level, what it intentionally omits, and the time window. It does not describe pagination response structure or default page sizes, but those are secondary for a list explicitly meant for status lookup.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds considerable meaning for the status parameter by enumerating all filter values (0-4), and it explains that the response is meant to expose order numbers and statuses. It does not add much for page_num/page_size, but the status semantics alone justify above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('分页查询视频翻译任务列表'), defines the scope (recent 15 days), and explicitly clarifies the list's purpose: find order numbers and check status. It also differentiates itself from get_video_translation_status by directing delivery use cases there.

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

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

Gives explicit when-to-use guidance: this list is only for finding order numbers and viewing status, not for fetching download links. It names the alternative tool to use for deliverables and tells the agent to pass videoTranslateOrderNo to get_video_translation_status.

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

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

No annotations are provided, so the description bears the full behavioral burden. It discloses important side effects: no translation, no task submission, no quota deduction, and that it may actually pop up a question to the user if supported. It also states what the tool returns: client-declared capabilities.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the most important scoping information and every sentence earns its place. It covers negative effects, purpose, invocation behavior, return value, and usage restriction without redundant filler.

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

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

Despite lacking an output schema and annotations, the description provides enough context for correct invocation: what it does, what it returns, when to call it, and what side effects to expect. The low complexity of a zero-parameter tool means no additional detail is required.

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

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

The tool has zero parameters, so there is nothing for the description to add beyond the empty input schema. The description adequately explains what happens on invocation, matching the baseline for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies it as a connectivity self-check tool with a specific verb and resource: verifying server-side MCP elicitation capability. It explicitly states what it does not do (translate, submit tasks, deduct quota) and distinguishes itself from normal translation workflow tools.

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

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

The description gives explicit when-to-use guidance: only call when troubleshooting whether the server can directly ask the user via MCP elicitation. It also states a clear exclusion: do not call in normal translation flow, which prevents misuse among the many sibling translation tools.

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

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

With no annotations provided, the description carries the full burden and exceeds it: it discloses real billing, the non-committing first call returning 409 with data.userPrompt and data.confirmToken, the binding of the token to order + subtitle texts with 15-minute expiry, and the caveat that pre-rewrite links remain valid but must not be presented as final. This is exceptional behavioral disclosure for a mutating, billing-affecting tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a dense wall of text, but every sentence carries critical operational information for a billing-affecting tool: the two-step protocol, token semantics, prerequisites, and follow-up routing. The billing warning and two-step requirement are front-loaded. A structured step list would improve scannability, but no sentence is wasted.

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

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

Despite having no output schema and no annotations, the description covers prerequisites, the exact 409 error contract, token lifecycle, the returned data.videoTranslateRewriteOrderNo field, the correct progress-checking tool, and the post-rewrite product retrieval flow. Nothing an agent needs to invoke this tool correctly and safely is missing for a tool of this complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds workflow-level meaning beyond the schema: it explains how confirm_token is obtained (from the prior 409 response), when it must be omitted vs. supplied, and that editing even one subtitle line invalidates prior consent — tying source_subtitles_txt and target_subtitles_txt to the confirmation semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening phrase '用编辑后的字幕重新生成视频' states a specific verb (rewrite/regenerate) plus resource (video) plus input (edited subtitles). It is immediately distinguishable from siblings: translate_video creates the original translation, get_video_subtitles fetches subtitles, and get_video_rewrite_status only checks progress.

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

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

The description gives exhaustive usage guidance: the original task must be status 2, the first call must omit confirm_token, the second call must include it after user consent, progress is checked via get_video_rewrite_status, and final products are re-fetched via wait_for_video_translation or get_video_translation_status. Every relevant sibling and its role is named explicitly.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It is exceptionally transparent: it details OCR detection before submission, the meaning of code=202 (not charged), the data fields submitted/charged/detecting, the is_ocr override behavior and its side effects, the OCR quota implications, and that non-200 errors come from the translation service rather than upload. This goes far beyond a basic description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, every sentence carries meaningful, non-redundant operational information. Important warnings are bolded (code=202, no charge), and the narrative is front-loaded with the primary purpose. The density corresponds directly to the complexity of the tool, and there is no filler.

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

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

There is no output schema, so the description must explain return fields and side effects, and it does: orders[].translateOrderNo, msg, ocrDetection, data.submitted/charged/detecting. It also handles edge cases (202 retry, service-busy 600, is_ocr override) and prerequisite steps. For a tool with this complexity, the description is remarkably complete.

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

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

Schema description coverage is 100% and the schema itself already provides detailed parameter descriptions. The tool description adds valuable operational context for parameters, especially is_ocr (when not to set it, what it means, and the warning about incorrect usage) and file_list (PDF scanning auto-detection). It slightly overlaps with schema content but enhances it with real usage guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states '提交文档翻译任务' (submit a document translation task), names the supported formats, and explicitly distinguishes this from other siblings such as translate_video and wait_for_translation. It also explains that images go through this same tool, eliminating ambiguity about which tool to use for a given input type.

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

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

Provides explicit workflow: first call get_model_list and get_supported_languages, then let the user choose model and target language. It states exactly when to use this tool vs alternatives, including using the returned translateOrderNo to call wait_for_translation directly instead of re-querying lists, and that images do not require a separate interface. It also gives specific retry instructions for code=202 and non-200 responses.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries full burden and does so well: it warns about SignatureDoesNotMatch if Content-Disposition is altered, tells the agent to request network permission upfront, and specifies post-conditions (upload success, then use objectKey). This goes far beyond a simple 'get link' statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence serves a purpose: purpose, execution caution, network handling, downstream chaining. Minor redundancy in the network instruction ('first time' vs 'don't try fail first') costs a little, but overall it's efficient.

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

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

Given no output schema, the description adequately reveals the expected return fields (uploadCommand, objectKey) and how to proceed. It could detail error handling beyond SignatureDoesNotMatch, but the essential workflow for successful use is fully specified.

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

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

Schema coverage is 100%, so the description need not repeat parameter meaning; it doesn't add extra semantics beyond mentioning the file path replacement in uploadCommand, which is not a direct parameter. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: obtain a pre-signed upload link for a document, then instructs executing the returned uploadCommand. This clearly distinguishes it from siblings like translate_document and upload_video, which handle different stages of the workflow.

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

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

Explains the exact workflow: get link, execute uploadCommand as-is, then call translate_document with objectKey. It also provides conditional guidance on network permissions. It doesn't explicitly name alternatives, but the chaining instruction makes the use case unambiguous.

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

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

没有 annotations，描述承担了全部行为披露责任。它详细说明了预签名地址 10 分钟有效期、uploadCommand 必须原样执行、Content-Disposition 不能改动否则 S3 报 SignatureDoesNotMatch，以及视频与文档不同端点/存储路径。这些都是调用成功与否的关键行为约束。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

描述主功能放在首句，随后是必要的执行警告、时效提醒、工具边界和后续步骤，信息密度高且每句话都有明确作用，没有冗余。

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

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

在无输出 schema 的情况下，描述充分说明了返回值的用法（uploadCommand、objectKey）、上传约束、有效期、与 upload_document 的边界，以及如何衔接 translate_video。agent 依据描述即可正确走完整个上传流程。

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

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

唯一参数 file_name_list 在 schema 中已有 100% 描述（“视频文件名列表”），描述正文没有补充格式、扩展名或列表约束。按高 schema 覆盖率基线评 3 分，描述没有增加超出 schema 的语义。

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

描述以明确的动词和资源开头：“取视频的预签名上传地址”，清楚说明工具职责。同时通过“视频不能用 upload_document 取链接”与同名兄弟工具做了区分，agent 不会混淆工具用途。

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

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

描述明确给出使用时机和完整工作流：取到地址后立即上传、只替换文件路径、上传成功后用 objectKey 调 translate_video；还显式排除上传文档场景。对何时用、何时不用、后续步骤均给出可执行指引。

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.