Skip to main content
Glama

translate

Destructive

Localizes game text by following the project's path graph, running in serial or parallel to maintain consistent terminology across files.

Instructions

按路径图翻译(串行或并行)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo调度模式
projectNo游戏项目根目录(默认当前目录)
workdirNo工作区目录,默认 <项目>/.gametrans
group_byNo按引擎结构的哪一级分组(默认按项目配置的 auto:适配层申报的首级);none = 这一轮不分组(逐条基线的对照臂)
providerNoprovider 名(mock / openai / agent:挂单等 agent 作答)
schedulerNo用哪个调度策略算计划(与 plan 命令同一个;默认 chapter-parallel,没申报章的项目自动退回严格分层)。seed-bulk 才有「第一轮只为产出资产」的两段形状 —— 它自称未校准,所以只是可选
asset_gateNo开工前资产预检的处置:block(默认)=「批准过的资产一条都进不了请求」时拒绝开工;warn = 只报不拦
batch_sizeNo一次调用最多装几条(封顶;段装得下就整段一次)
no_produceNo关掉「跑完把译文变成资产」(术语候选);对照臂用,默认开着
unit_scopeNo这一轮只翻这些单元(unit_id 列表,逗号分隔);不给 = 全图。分块/续跑用:已完成的分块重跑时一个 token 都不该再问模型
batch_unitsNo小批量并行:把本来一层一层串行的计划按不超过这么多**单元**攒成一批,批内并行、批间串行(0 = 不攒,严格按分层走,默认)。视觉小说的图是一条长链(真靶 32 层、27 层只有 1 个单元),攒批把轮数按批量降下来;代价是批内后面的单元看不见前面刚定下的叫法 —— 每批跑完由「合并术语」补,见 auto_approve_terms
concurrencyNo并行度
round_linesNo一个单元**分几轮**问完(0 = 一次发完,默认;>0 = 每轮最多这么多条)。长单元一次发不完时用它:每轮只发这一轮的句子,前几轮的原文与译文由会话历史带着(不重发、不写「继续」),轮内串行。撞输出上限会自动转多轮(每轮 150 条)并把这一轮对半再切,整批报废因此变成只丢一轮
start_phaseNo从计划的第几个阶段开始跑(1 起数)。续跑用:第一阶段不会重问一次模型
unit_budgetNo一个单元一次最多问几条槽位(0 = 不切,默认)。慢模型上单次请求有物理上限(真靶实测 90 条的单元在 300 秒处被服务端回 HTTP 400),切开才拿得到译文;切出来的段仍是同一个单元,段间串行并把前一段译文交给后一段当上下文
predecessorsNo前驱集怎么算:knowledge(默认,控制边 + 知识边 —— 一个区域等它引用的实体的引入场,章内按它分波、章间照旧按章序)/ control(只看控制边 = 老行为)
context_layersNo这一轮只走检索阶梯的哪几层(direct,structural,knowledge,memory,targeted);不给 = 阶梯全开。给消融实验用:声明了才真的少取那几层
reuse_importedNo把读进来的已有译文(resource harvest)也当命中复用;默认不认 —— 它们没有知识指纹,证明不了是在当前术语状态下翻的
target_languageNo目标语言
stop_after_phaseNo跑完第几个阶段就停(0 = 不停)。第一轮=计划的第一个阶段:跑完停下来,等人或 agent 给资产拍板,再用 --start-phase 接着跑
memory_reuse_modeNo命中的句子怎么处理:keep(默认)=请求里摆出原文和已定译、只要新句子;polish = 命中句照样要模型回译(可以为了上下文通顺提出改动),改动只记成修订提案、不就地生效
auto_approve_termsNo每批跑完合并术语:同一个原文在**不同的这么多批**里各自被申报过一次且译名一致 → 由 agent 身份自动批准,下一批就真能用(默认 2;0 = 关,只落候选,全交给人)。撞车(同一原文多种译名)谁都不批,记进报告的 term_conflicts;语料判据说「不像专名」的不自动批准;已否决的不复活
retry_on_violationNo结构校验没过时重试几次(受 max_attempts 封顶)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

C2.5/5.0
Behavior2/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, yet the description adds nothing about what is written or overwritten, that it produces translation assets, that terms can be auto-approved and become live, or that it can be long-running and resumable. With annotations in place the description is expected to add exactly this kind of context, and it adds none.

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

Conciseness3/5

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

A single front-loaded phrase with zero filler, so nothing needs trimming. But for a tool of this complexity the brevity crosses into under-specification: the one sentence is not sized to the job, so it earns its place only marginally. Short does not equal well-structured here.

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

Completeness2/5

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

No output schema exists, and the description does not compensate: it omits the plan-then-translate relationship, resumability (start_phase/stop_after_phase/unit_scope), provider and scheduler selection, and the asset/term side effects. The rich per-parameter schema descriptions carry most of the load, but the top-level description is not complete enough for a tool with this many interacting options.

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 every one of the 23 parameters carries a detailed behavioral note, so the schema does the heavy lifting. The description contributes only the serial/parallel distinction, which duplicates the mode enum rather than adding meaning. Baseline 3 applies.

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

Purpose3/5

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

States a verb (翻译) and a method (按路径图) plus the execution shape (串行或并行), so the core action is identifiable. However, '路径图' is unexplained domain jargon and nothing distinguishes this execution tool from the adjacent pipeline siblings (plan, unify, writeback) that an agent would see in the same list. Purpose is clear but under-articulated for a 23-parameter engine.

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

Usage Guidelines2/5

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

The description gives no when-to-use guidance and never names the alternative. It does not say that `plan` produces the schedule this command executes, nor when to choose serial vs parallel (that lives only in the mode enum). An agent must infer the pipeline position from sibling names alone.

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