Submit 1–50 arXiv, DOI, or paper-page links to batch-translate LaTeX sources into Simplified Chinese and compile Chinese PDFs, returning a job ID.
提交 1–50 个论文链接，会调用付费 DeepSeek API。后台批量翻译并编译，返回 job_id。
work_dir 为用户当前工作目录绝对路径。main_tex 仅在单篇论文有多个主文件时指定相对路径。 同一目录同一链接列表不会重复启动。部分失败继续处理其他论文。
| Name | Required | Description | Default |
|---|---|---|---|
| links | Yes | ||
| main_tex | No | ||
| work_dir | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=true), yet the description adds genuinely new behavioral facts: it invokes a paid DeepSeek API (cost), runs as a background async batch (returns job_id), deduplicates identical submissions, and continues on partial failure. This exceeds what annotations alone provide, though it omits rough cost/scale 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 purpose and return value come first, followed by parameter notes and then behavioral caveats — a sensible front-loading order. Every sentence carries information, with only minor density from mixed-language technical terms.
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 exists, but the description states the return (job_id) and the async model, and the presence of resume_translation/arxiv_zh_status implies a pollable job lifecycle. It is close to complete for an async submission tool; a note on how to retrieve results would close the loop.
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?
With 0% schema coverage, the description carries the burden and largely does: work_dir is defined as the absolute path of the current working directory, and main_tex as a relative path used only when a single paper has multiple main files. links is only implied by '1–50 paper links' rather than defined explicitly, leaving a small gap.
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 (submit 1–50 paper links for batch translation and compilation) and an outcome (returns job_id), which distinguishes it from siblings like get_translation and resume_translation. It doesn't explicitly name those siblings, so sibling differentiation is implicit rather than stated.
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 conveys operational context — a 1–50 link batch, deduplication on identical directory/link lists, and continued processing on partial failure. However, it never explains when to choose this over resume_translation or how it relates to arxiv_zh_status/get_translation, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.