gametrans

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

"认领" (claim) describes taking ownership of a queue item, which changes local state so other agents no longer see it as pending — a write. The annotations declare readOnlyHint=true and destructiveHint=false, so the description contradicts the declared safety profile. It also omits whether claiming is reversible, what happens if no pending items exist, and whether the claimed item can be released.

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?

One front-loaded sentence states the action first, with the explanatory parenthetical second; there is no filler. It is tight, though the parenthetical's phrasing ("本该发给 API 的完整请求") is opaque enough to require a re-read.

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 queue-consuming tool with no output schema, the description does not say what the returned payload looks like, how the agent is expected to answer the claimed request, what happens on an empty queue, or whether the claim expires. An agent cannot complete the intended workflow from this definition alone.

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 parameters are optional strings with their own descriptions (project root, workdir default), so the schema already carries the semantics. The tool description adds nothing about resolution order or how project/workdir interact with the claimed item, 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?

Names a concrete action and object: fetch the oldest pending order and claim it, with a parenthetical that explains the underlying flow (a request that would have gone to the API is answered locally by the agent using its own quota). That is much more than a restatement of the name and lets an agent distinguish it from agent_submit/agent_status, though the sibling relationship is only implied.

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 explicit when-to-use guidance: no statement of when to call this versus agent_status or agent_submit, no preconditions (must a project/workdir exist first?), and no mention of what to do with the fetched item afterwards. The parenthetical hints at context but never states the trigger or the follow-up.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds what is surfaced (counts of waiting vs. answered-but-uncollected), which is useful, but says nothing about return shape, scope, or whether the queue is global vs. per-project.

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 single compact clause with zero padding, and the key output content (waiting / answered-uncollected counts) is front-loaded. It is arguably spare given that no other aspect is addressed, but every word 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?

For a simple read-only status tool with two optional params and no output schema, the description adequately conveys what the agent gets back (the two queue counts). No mutation, auth, or rate-limit concerns need addressing given the read-only annotations.

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 only two optional parameters (project, workdir), so the schema already carries full parameter meaning. The description adds no parameter-level detail beyond what is documented. 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 names a concrete verb (看/view) and a concrete resource (挂单队列, the pending-order queue), and specifies what it reports: how many are waiting and how many were answered but not yet collected. It is clearly distinct from agent_next and agent_submit, though it never names them explicitly.

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 when-to-use guidance, no prerequisites, and no mention of sibling tools such as agent_next or agent_submit. The description only states what the tool reports, leaving the agent to infer that it is for inspecting (rather than advancing) queue state.

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 already declare this is a write operation (readOnlyHint=false) and destructive (destructiveHint=true). The description adds genuine context beyond them: only pending orders accept submissions, and the answer rejoins the same validation chain. It still does not disclose what 'destructive' means here (does resubmitting overwrite a prior answer?) — an important gap for a destructive 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?

A single front-loaded sentence with the core action stated first and the constraints in a compact parenthetical. No wasted words, though very terse for a destructive write operation.

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 should carry return/error behavior, and it does not say what happens on success or when no pending order is found. For a destructive write tool with zero required params it is minimally adequate but leaves the agent guessing about failure modes.

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 all four parameters (answer, project, workdir, request_id). The description adds nothing about parameter format or defaults, so 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?

States a specific verb (submit/交) and resource (an answer to a pending order), and the parenthetical clarifies the target is a pending 挂单. An agent can distinguish this from agent_next (which produces the order), though the sibling is not named directly in the description.

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 constraint '只有 pending 的单能收' tells the agent when submission is valid (only for pending orders), which is meaningful guidance. However it does not name alternatives or state what to do if no pending order exists (e.g. call agent_next first). Usage is implied rather than explicit.

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 describes a purely informational lookup ("report where the files are"), while the annotations declare readOnlyHint=false and destructiveHint=true. These directly conflict: either the tool mutates state (and the description omits that entirely) or the annotations are wrong, and the description gives the agent no way to resolve which.

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 single short sentence with no filler and the purpose is front-loaded. It is arguably too terse rather than padded, and "四层" is left unexplained, which keeps it just short of full marks.

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 takes no required parameters and its schema is fully documented, so little is needed. But with no output schema, the description could reasonably say what the report contains (four layer names and their resolved paths) and how the layers are ordered; that is missing, and the conflict with the annotations is left unaddressed.

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%: both `project` and `workdir` carry their own descriptions in the schema, including the default resolution for workdir. The description adds no additional meaning about these parameters, so the 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 names a concrete verb (report/announce) and resource (the file locations of the four config layers), so an agent can tell this is a path-lookup tool rather than a value-manipulation tool like config_show or config_set. It does not, however, name or exclude any sibling explicitly, and the phrase "四层配置" is never defined.

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 statement of when to use this tool versus config_show, config_set, config_unset, or config_providers, all of which live in the same config family. The agent must infer the distinction purely from the name and one-line description.

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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds nothing beyond that: no indication of whether providers are discovered from the project/workdir, no auth or environment requirements, and no return shape. It merely restates the purpose.

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 single short, front-loaded sentence with zero padding. It is efficient, though arguably terse to the point of under-specification for a tool whose sibling set is large.

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 read-only list operation with full schema coverage and annotations, the description is minimally adequate. It does not clarify what the listed providers are scoped to (project vs workdir) or what the output contains, but with no output schema that omission is minor.

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 optional parameters (project, workdir) are fully documented in the schema. The description adds no parameter meaning, which is acceptable given the schema does the work, hence the baseline 3.

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: list the available translation providers. That is clear enough to distinguish it from mutation siblings like config_set/config_unset, though it does not explicitly differentiate itself from config_show or config_path.

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 on when to call this versus config_show, config_path, or engine_list, and no prerequisites or context for use. The agent must infer usage entirely from the name.

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 already declare readOnlyHint=false and destructiveHint=true, so the mutation/overwrite risk is signalled structurally. The description adds the scope-selection behavior but never confirms what happens to an existing value, whether a write is destructive to the prior setting, or what the return looks like — modest added value over annotations.

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 single compact sentence plus a parenthetical; the default behavior and the global-layer override are front-loaded with no filler. Efficient and well-ordered.

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?

Tool has annotations, full schema coverage, and no output schema, so the burden is light and the scope ambiguity is addressed. However, as a destructive write tool it should say whether setting a key overwrites an existing value, which is the main remaining 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 coverage is 100%, so key/value/project/workdir/global_scope are already documented. The description reinforces the layer semantics (project default vs global) but adds no syntax or format detail beyond the schema, so baseline 3 applies. Note it references a '--global' flag while the schema exposes a boolean 'global_scope' param, which could mildly confuse mapping.

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 (一项配置), and immediately clarifies the two scope layers (项目层 vs 全局层). It is distinguishable from config_show/config_unset/config_path by the write verb, though it never names those siblings explicitly.

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 default (project layer) and the opt-in alternative (global layer, 'once configured, applies to all projects'), which is genuine when-to-use guidance. It does not clarify when to use this over config_unset or any prerequisite state, so guidance stays implied rather than explicit.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioral fact beyond them: the output includes per-item layer provenance. It says nothing about formatting or scope of the merge, so this is useful but thin.

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 single short sentence with the core action front-loaded and zero filler; the parenthetical detail is the only extra and it earns its place. Sized appropriately for the tool's simplicity.

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 does carry the burden of explaining what comes back, and it covers the key point (current config plus per-item layer origin). Combined with complete parameter docs and read-only annotations, an agent has enough to call and interpret it, though a note on output shape or merge scope would round it out.

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 (project, workdir) are already documented in the schema. The description adds no additional meaning such as precedence between the two paths or default resolution behavior. Baseline 3 applies when the schema does the heavy lifting.

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 adds a distinguishing detail: it shows which layer each item comes from, which separates it from a plain dump. It doesn't explicitly contrast with read-only siblings like config_path or config_providers, but the purpose is unambiguous.

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?

Usage is implied by the verb — read the effective config — but there is no explicit when-to-use or when-not-to-use guidance, and no routing to config_path/config_providers for agents looking for file locations or provider info instead. Adequate but with a clear gap given four config siblings.

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 already declare destructiveHint=true, and the description adds the non-obvious behavioral consequence: removal triggers layered fallback rather than a reset to default, and the global_scope param allows targeting the global layer. It stops short of saying exactly what is destroyed or whether removal is reversible.

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 single tight sentence with the key behavioral distinction front-loaded and the clarifying parenthetical inline. Nothing superfluous, though it is terse enough that more routing guidance could have fit.

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 four-parameter, no-output-schema mutation with annotations covering the safety profile, the description conveys the core layered-fallback semantics. It omits interaction details between project and global_scope and the reversibility of the operation, but is largely sufficient to call 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?

Schema coverage is 100%, so all four parameters are already documented; the schema carries the heavy lifting. The description's '某一层' and layer-fallback wording loosely maps to the project/global_scope layer concept but adds no format or syntax detail. 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?

States a specific verb+resource: deleting one item from a layer so it falls back to the next layer. The parenthetical '不是设成默认值' sharply distinguishes the effect from a default-reset, which is genuinely clarifying. It does not, however, name how it differs from siblings like config_set.

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 explicit when-to-use or alternative routing, but the '回落到下一层' semantics imply the scenario (removing an override so a lower layer takes effect). Usage is implied rather than stated, and no sibling such as config_set is named.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that: no mention of detection method, behavior on unknown/ambiguous engines, or what the result represents.

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 single short, front-loaded sentence with no filler. It is appropriately sized, though the extreme brevity is partly why other dimensions are thin.

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 should at least indicate what detection yields (an engine name, type, or confidence), but it does not. For a query tool whose entire value is the return value, this is a meaningful 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 all three parameters (path, project, workdir) documented in-schema including default behavior. The description's '目录' loosely aligns with the path parameter but adds no syntax or format detail beyond the schema, so 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?

States a specific verb ('探测'/detect) and resource ('目录使用的是什么引擎'/which engine a directory uses), so an agent knows it identifies the engine for a given directory. However, it offers no differentiation from siblings like engine_info or engine_list, which likely also surface engine 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 indication of when to use this tool versus engine_info, engine_list, or engine_options, nor any prerequisites. The agent must infer the routing from the name alone.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that – no mention of what 'capabilities' contains, whether an engine must be detected/initialized first, or any return behavior.

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 single short front-loaded phrase with no wasted words. It is terse to the point of under-specification rather than verbose, but structurally there is nothing to trim.

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 carries the burden of explaining what the tool returns, yet 'capabilities' is never defined. For a read tool that takes an engine pack name and project/workdir, the agent has no idea what information comes back or how it relates to engine_list/engine_options.

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 all three parameters (name, project, workdir). The description only gestures at the 'name' concept via '某个引擎支持包' and adds no format or selection detail beyond the schema, so 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?

States a verb+resource ('查看...能力' – view capabilities of an engine support pack), which is more specific than a tautology. However it does not distinguish itself from close siblings such as engine_list, engine_detect, or engine_options, leaving the agent to guess which one to call.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives. The only implied usage is the obvious one from the name; nothing tells the agent when this tool is the right choice over engine_list or engine_options.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no hint about what the listing contains, whether it reflects on-disk state, or how it relates to engine_detect/engine_info. Minimal added value.

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 single short sentence with no wasted words. It is front-loaded, though the extreme brevity means it stops short of being fully informative rather than being efficiently complete.

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 two-optional-parameter read tool with no output schema, the description is adequate but thin — since no output schema exists, a sentence on what the listing returns (package names, paths) would improve completeness without much cost.

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 both optional parameters (project, workdir) fully documented in the schema, so the baseline is 3. The description contributes no additional parameter meaning such as default resolution behavior.

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+resource: list installed engine support packages. This is clear, but it doesn't distinguish itself from the many engine_* siblings (engine_info, engine_detect, engine_options), leaving the agent to infer the difference between listing support packages and inspecting engine details.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the crowded engine_* family. The agent must infer the usage context entirely.

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 already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: no indication of reversibility, whether the option is removed permanently, or what error occurs for an unknown key. Little value beyond the annotations.

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 single short clause with no waste, but it is under-specified rather than elegantly concise. It is front-loaded, which is a positive, but there is nothing else to front-load.

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 destructive mutation with no output schema and no guidance beyond annotations, the description is too thin. It never says that the option is removed from the engine config, whether a confirmation or permission is required, or how it relates to engine_option_set.

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?

All three parameters are documented in the schema at 100% coverage, so the baseline is 3. The description adds no meaning about which key identifies the option, which option namespace it targets, or how project/workdir interact.

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 verb+resource (delete an engine private option), which is more than a tautology, but it is minimally specified and does not differentiate itself from the sibling engine_option_set beyond the opposite direction. An agent can guess its purpose but gets no scope details.

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?

No guidance on when to use this versus engine_options/engine_option_set, no prerequisites, no note about whether the key must exist or what happens if it does not. Usage is only implied by the name and the word '删掉'.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds what is being read (private options and official SDK toolchain status), but does not disclose return format, scope, or authorization requirements. With annotations present, a 3 is appropriate.

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 concise phrase with no wasted words. It is front-loaded and appropriately sized, though it could benefit from slightly more structure to separate the two concepts it covers.

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 read-only status tool with annotations covering safety, full schema parameter descriptions, and no output schema, the description is nearly complete. It identifies the resource being read, though it could clarify project scoping to be fully self-contained.

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 (project and workdir) are already fully documented in the schema. The description adds no additional parameter meaning or syntax, so baseline 3 is correct.

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: '查看' (view) the current engine's private options and external toolchain (official SDK) status. It is clear what the tool does, but it does not differentiate from siblings like engine_info, engine_list, or engine_option_set/clear.

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 explicit guidance on when to use this tool versus alternatives. It implies a read/status check but provides no context, prerequisites, or exclusions regarding sibling tools that also deal with engine information.

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 already declare that this is a write operation with destructiveHint=true, so the agent knows it mutates state. The description adds scope ('引擎私有选项') and an example, but does not explain overwrite behavior, permissions, or other side effects of setting the option.

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, front-loaded sentence with no wasted words. It states the core action and gives a helpful parenthetical example.

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?

Purpose is clear and the schema fully documents the parameters, while annotations cover the mutation safety profile. However, the description omits usage guidelines and mutation side effects, leaving it at minimum viable completeness for a destructive setter with no output schema.

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%, and all four parameters (key, value, project, workdir) are documented in the schema. The description mentions key/value implicitly via '选项' and gives an example, but adds no syntax or semantic detail 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 gives a specific verb (设置) and resource (引擎私有选项), with an example clarifying the kind of option. It does not explicitly differentiate from siblings such as engine_option_clear or engine_options, but the set/clear/list distinction is strongly implied.

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 when-to-use, when-not-to-use, or alternative-tool guidance. The example hints at one use case, but prerequisites and selection relative to engine_option_clear, engine_options, or config_set are absent.

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 already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating operation. The description adds one genuinely useful behavioral fact — the edge only affects scheduling order once the direction is confirmed — but it never explains the destructive side (does recording overwrite an existing edge?), nor permission or validation requirements, despite carrying a destructiveHint.

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 single short sentence with the scheduling caveat front-loaded in the parenthetical — nothing wasted and no filler. It is arguably too terse for a 7-parameter mutating tool, but as pure structure it is clean and readable.

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 7-parameter, destructive, no-output-schema mutation, one line is thin. It does not say what confirmation entails, whether repeated calls overwrite, what happens with the default 'agent' direction, or how it relates to graph_undepend/graph_dependencies. The scheduling note is the only substantive context provided.

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 every parameter including the direction enum and its 'only control_flow/agent participate in sorting' note is already documented. The description merely restates the direction/scheduling relationship rather than adding syntax, defaults, or examples 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 names a specific verb+resource pair ('记下/确认一条依赖边' – record/confirm a dependency edge), which is enough for an agent to distinguish it from siblings like graph_undepend (removal), graph_dependencies (listing), and graph_node. It does not explicitly contrast itself with those siblings, but the action is unambiguous.

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 parenthetical '（确认方向后它才参与调度排序）' hints at the condition under which the edge becomes effective for scheduling, which is a usage-relevant cue. However there is no explicit when-to-use statement, no prerequisite (e.g. must graph_node exist first?), and no direction on choosing between graph_depend and graph_undepend when an edge already exists.

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 already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description does add output-structure context (candidate vs confirmed edges reported separately), which is useful and not present in annotations, but it says nothing about scope (whole project vs. a node), ordering, or how the two groups are returned.

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?

One short sentence with no filler, and the most decision-relevant detail (candidate vs confirmed separation) is front-loaded. It is bordering on too terse for a graph-inspection tool, but nothing 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?

With no output schema, the description carries the burden of explaining what is returned, and it only partially does so: it names the two categories but not the edge fields (source, target, type, certainty) an agent would need to consume the result. For a read-only list tool with fully documented params, this is adequate but with clear gaps.

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 parameters (project, workdir) are documented in the schema. The description contributes no parameter meaning at all, not even which project/workdir the listed edges belong to, 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?

States a specific verb+resource (list dependency edges) and adds a meaningful qualifier: candidates (direction unconfirmed) are reported separately from confirmed edges. This distinguishes it in spirit from the sibling graph_depend (which implies creating/depending), but the description never names graph_depend, graph_show, or graph_node, so an agent must infer the boundary from the plural name alone.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The description never says to use this instead of graph_show or graph_node when inspecting the dependency graph, so selection among the closely-named graph_* siblings is left entirely 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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating, destructive operation. The description adds that the mutation targets knowledge edges and reveals their source, but it does not mention that replace mode also removes control-flow ordering edges or describe irreversibility or permissions. With annotations covering the safety profile, this partial context earns a 3.

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, front-loaded sentence with no wasted words, but it is arguably too terse for a three-mode, destructive graph mutation tool. It is concise yet under-specifies important behavioral and usage details, keeping it from a higher score.

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 destructive annotations, full schema coverage, and lack of an output schema, the description need not explain return values. However, for a tool with three distinct modes and a destructive replace behavior, it omits enough usage and impact context that an agent must rely entirely on the schema to invoke it safely. It is minimally complete but not rich.

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 mode, project, and workdir parameters are fully documented in the schema itself. The description only hints at removal ('或撤掉') and adds no syntax, default, or format details beyond what the schema already provides. 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 verb and resource: writing knowledge edges into the graph, or removing them. It also notes the source of the knowledge ordering (term book + original-text hits), which helps distinguish it from pure dependency-edge tools. It does not explicitly name a sibling tool, so it falls short of a 5.

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 offers no explicit when-to-use guidance or alternatives. It only says 'write ... or remove' without indicating when an agent should choose this over graph_depend, graph_undepend, or other graph tools. The mode enum in the schema implicitly covers apply/replace/remove, but the description itself provides no routing context.

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 already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no behavioral context beyond restating 'view'—no return format, no pagination, no auth requirements, and no insight into node structure.

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 single short sentence with zero filler, and the identification method is front-loaded. It is efficient, though its extreme brevity borders on under-specification for a tool with three optional parameters.

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 read tool with full schema coverage and safety annotations, the core action is communicated. However, with no output schema and no return-value description, the agent does not know what a 'node' contains, and the lack of sibling differentiation leaves some ambiguity.

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 all three parameters. The description names the accepted identifier forms for 'ref' but adds no syntax, format, or default-value information beyond what the schema 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 states a specific verb (查看/view) and resource (节点/node), and notes the identifier forms accepted. However, it does not differentiate this tool from sibling graph_show or other graph_* tools, leaving the agent to infer the boundary.

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 on when to use this tool versus alternatives such as graph_show, graph_dependencies, or graph_knowledge. It only states what the tool does, not when it should be selected.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioral trait beyond the annotations: results are ordered by weight. It says nothing about scope, pagination limits, or how many nodes exist, but with annotations carrying the safety burden this is minimally acceptable.

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 single tight sentence with no filler, and the key ordering behavior is front-loaded. It is efficient, though the terseness borders on under-specification rather than being genuinely complete.

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, and the description does not explain what a 'path graph node' contains or what the returned list looks like. For a tool with three parameters and no return-value contract, the description leaves the agent without enough context to interpret results confidently.

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 every parameter (limit, project, workdir) is already documented in the schema with defaults and Chinese explanations. The description contributes no additional parameter meaning, which is the correct baseline when the schema does the heavy lifting.

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 Chinese phrase states a verb and resource ('list path graph nodes by weight'), so the basic operation is identifiable. However, it does not differentiate this listing tool from its close siblings graph_node, graph_dependencies, or graph_knowledge, and the term 'path graph' is left undefined. Adequate but with clear gaps.

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?

No guidance on when to call this versus graph_node, graph_dependencies, or graph_knowledge, and no prerequisites or context stated. The agent must infer selection purely from the name.

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 annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds nothing beyond that — it does not say whether the delete is reversible, what happens if the edge does not exist, or what validation/auth constraints apply to a mutation.

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 single terse phrase with zero filler and the action front-loaded. It is efficient, though so short that it borders on under-specification rather than optimal conciseness.

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 4 parameters, none marked required, and no output schema, the description should clarify which inputs are needed and what the result is. It provides none of that, leaving the agent without enough information to invoke a destructive mutation confidently.

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 every parameter (source, target, project, workdir) documented in the schema itself, so the baseline is 3. The description contributes no additional parameter meaning such as which of source/target are mandatory or the id format expected.

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 (删掉/delete) and resource (依赖边/dependency edge), so the agent knows exactly what operation is performed. However, it makes no attempt to distinguish itself from siblings like graph_depend (add edge) or graph_dependencies, leaving the agent to infer directionality of the 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?

No when-to-use, when-not-to-use, or alternative-tool guidance is given. The agent must guess whether this is the right tool versus graph_depend, graph_node, or graph_dependencies based purely on the name.

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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that the tool also performs consistency validation on the extraction layer, which is useful behavioral context, but it says nothing about what the validation reports, whether export can fail, or what happens on inconsistency.

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 single compact sentence with the export action front-loaded and validation appended. It is efficient, though the two bundled operations are not separated or prioritized.

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 read-only tool with full schema coverage and no output schema, the description is minimally adequate. It leaves unclear how export and validation interact, what the validation scope is, and what the caller receives, which matters since no output schema documents the return shape.

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 limit, project, and workdir are fully documented in the schema itself. The description adds no extra meaning about parameter syntax or interplay, 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 pairs the verb 导出 (export) with a specific resource, Localization IR, and adds a second action, validating extraction-layer consistency. It compensates for the opaque tool name 'ir', though it does not distinguish itself from siblings like scan or pack that may also touch IR data.

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 when-to-use guidance, no mention of prerequisites or ordering relative to scan/pack/translate, and no alternatives named. An agent cannot tell from this description when exporting IR is the right call versus other pipeline steps.

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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful scope context by naming the three fact categories, but does not discuss output format, permissions, or any other behavioral trait beyond what the annotations and tool name imply.

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 single front-loaded sentence with a colon and a compact list of three facts. Every clause earns its place, with no redundancy or 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?

For a simple read-only inspector with full parameter schema coverage and safety annotations, the description adequately tells the agent what facts will be returned. It does not define output structure or relation to sibling tools, which leaves a small gap for a tool with no output schema.

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 each of the three optional parameters already has its own schema description. The tool description adds no parameter-level meaning or syntax beyond what the schema provides, making the baseline 3 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 (语言包事实), then enumerates the three fact categories: recognized language codes, font sources, and current contents of the language directory. Clear enough to call, but it does not differentiate itself from any sibling tool, so it cannot reach a 5.

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 implies when to use it by listing the facts it exposes, but gives no explicit when-to-use, when-not-to-use, prerequisites, or alternative tools. Usage is inferable but not guided.

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?

注解声明了 destructiveHint=true 和 readOnlyHint=false，因此安全配置由结构化数据承担。但描述没有增加任何内容——没有说明会写入或覆盖什么（例如现有补丁文件），没有说明写入位置，也没有说明打包是否会改变源产品。

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，并且是一个带有 destructive 提示的变更类工具，描述对于一个会写入磁盘产物的命令来说太过单薄。补丁生成在哪里、是否会覆盖先前的输出、需要哪些输入产物——这些内容都缺失了。

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?

两个参数（project、workdir）的 schema 描述覆盖率为 100%，因此 schema 已经记录了它们的含义和默认值。描述未增加任何语法或语义细节，这是 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?

明确给出了动词（封包）+ 资源（翻译产物）+ 产出物（可分发补丁），是一个非常具体且易于识别的目标。但它并未说明使其与诸如 writeback/unify 之类的同类工具区分开来的原因。

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?

没有说明何时使用此工具、前置条件是什么，也没有提及替代方案。打包在翻译流水线中的位置（在 translate 之后）只能靠推测，没有提供任何指导。

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that this is a preview of the run order, which reinforces the non-mutating nature, but says nothing about fallback behavior, cost, or what the returned plan actually contains beyond 'region → ordered stages'. Adequate but thin given annotations carry the main load.

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 single compact sentence with zero waste, front-loading the concrete outcome (region → ordered stages). The nested parenthetical is slightly dense for a one-liner but nothing is 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?

With no output schema, the description should help an agent understand the returned plan, but it only broadly sketches the shape. It also references returned 'schedulers' only through the schema text, not the description, leaving the return contract under-explained for a planning 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?

Schema description coverage is 100%, so the schema fully documents all four parameters including the 'predecessors' enum and 'scheduler' default. The description only alludes to the scheduler ('可指定调度策略'), adding nothing beyond what the schema already states. 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 gives a specific verb ('看' – view/preview) and resource (the order in which the translation run will proceed: region → ordered stages), which is distinguishable from the write-oriented sibling 'translate'. However, it does not name or contrast any sibling (e.g. translate, tasks, graph_show), so an agent must infer that this is a dry-run/planning preview.

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 explicit when-to-use guidance, no mention of prerequisites, and no alternatives named. The implied use (inspect the execution order before/instead of running 'translate') is left entirely 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?

The annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is known. The description only adds the auto-detect engine behavior and does not explain what gets created or overwritten, which is important context for a destructive initialization 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?

The description is a single compact phrase that is front-loaded with the main action. Every word earns its place 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?

With five fully documented optional parameters and annotations covering destructiveness, the structured fields carry most of the burden. However, the description omits key init semantics such as whether an existing workspace is overwritten, so it is only minimally 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%, so every parameter is already documented in the schema. The description adds no parameter-level detail beyond noting the engine auto-detection default, making the baseline score 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 verb and resource: initializing the gametrans workspace, with an engine auto-detection default. It is clear enough to distinguish from general status/config tools, but it does not explicitly differentiate itself from siblings like engine_detect or project_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?

It describes the action but gives no when-to-use, when-not-to-use, or alternative-tool guidance. An agent can only infer that this is for first-time setup, without explicit context about ordering or prerequisites.

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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds nothing beyond that — no scope of "各层", no indication of whether results are cached, computed, or may be stale.

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 single short sentence with no padding, but it is under-specified rather than genuinely concise — the one clause it contains is the vague term "各层" that a reader still needs resolved.

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 only readOnly annotations, the description carries the burden of explaining what status data is returned and for which layers. It says nothing about either, leaving an agent unable to predict the response.

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 only two optional path parameters, so the schema fully documents them. The description repeats none of that and adds no semantic detail, making the baseline 3 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 verb (查看) and resource (项目状态), so the basic action is clear, but "各层" (each layer) is undefined and the tool is not distinguished from close siblings like agent_status, skeleton_status, or staleness. An agent cannot tell from the text which status view this returns.

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 on when to call this versus the many other *_status and reporting siblings. No prerequisites, no exclusions, no alternative named.

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 already declare destructiveHint=true and readOnlyHint=false, so the agent knows it mutates state. The description adds that this is a policy override (default forbidden, declaration allows), which is useful context. However, it doesn't detail side effects, reversibility, or required permissions beyond the annotations.

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 single, front-loaded sentence with no wasted words. It is appropriately sized for a tool whose parameters are fully documented in the schema.

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 mutation tool with a fully documented schema and safety annotations, the description conveys the core purpose and permission rule. It falls short on when to use it relative to sibling tools and what effects the deviation declaration has, leaving some gaps.

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 all six parameters. The description adds no syntax or format detail for any parameter and may even imply a 'criterion' parameter that does not exist in the schema, 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 (声明/declare) and resource (偏离/deviation) and explains that the deviation is from a validation criterion, with the default-disallow rule. It does not explicitly contrast with resource_deviation_list or resource_deviation_remove, but the add action is clear from the name and text.

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 provides a clear condition for use: deviations are disallowed by default and this declaration is what permits them. It does not name alternative tools or when not to use, but the context is sufficient to know this is for intentional exceptions.

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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered by structured data. The description does add semantic value by defining what counts as a deviation, but it says nothing about the result shape, ordering, or whether the project/workdir defaults are resolved silently.

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 single front-loaded line with no filler; the verb and resource lead. Slightly terse — one clause about the return contents would have fit without bloat.

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 two-optional-parameter read-only listing with no output schema, the definition covers purpose and domain meaning adequately, and the schema covers the parameters. The only real gap is an indication of what the agent receives back, which is largely inferable from the name.

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 optional parameters (project, workdir) carry their own defaults and explanations, so the schema does the heavy lifting. The description adds no parameter-level information beyond it, which is the expected baseline of 3.

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?

Names a specific verb (列出/list) and resource (声明的偏离/declared deviations), and the parenthetical gloss ('有意留空 / 经批准的表达式改写') pins down exactly what a deviation is, so the agent knows the domain object. It does not explicitly distinguish itself from the sibling resource_deviation_add/remove pair, though the verb makes the read variant inferable.

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?

Usage is only implied: the fact that these deviations are *declared* (i.e. already registered) hints this is the inspection step in the add/list/remove workflow. There is no explicit when-to-use statement, no exclusion, and no mention of alternatives such as resource_term_list or resource_supplement_list that an agent might confuse it with.

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 already declare destructiveHint=true and readOnlyHint=false. The description adds almost no behavioral context beyond repeating that something is deleted: it does not explain irreversibility, the kind-empty cascade behavior, permissions, or what exactly happens to affected translation records.

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 single front-loaded sentence with no wasted words, but for a destructive four-parameter tool it is too terse and omits structure that would make the definition safely usable.

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 destructive mutation with four parameters and no output schema, the description is incomplete: it does not explain deletion scope, side effects, or when the operation should be chosen over related tools.

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 input schema already documents all four parameters, including the special empty-kind behavior. The description adds no additional parameter meaning, making the baseline score of 3 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 verb and resource: delete one deviation declaration. It is clearly different from resource_deviation_add and resource_deviation_list by verb, though it does not explicitly name those alternatives.

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 versus resource_deviation_list or resource_deviation_add, no prerequisites, and no mention of confirmation or alternatives.

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?

注解声明 readOnlyHint=false、destructiveHint=true，但描述完全没有披露任何破坏性/写入行为，只说「只读游戏」，容易让 agent 误判这是安全只读操作。描述唯一补充的行为信息是「观察出来的对应不进术语书」，略有一点价值，但对一个被标记为破坏性的工具远远不够。

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?

这是一个 5 参数、被标记 destructive、且无 output schema 的写入型工具，描述却未说明写入翻译记忆的性质、是否会覆盖既有条目、返回什么。对一个破坏性工具来说，关键上下文缺失。

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 描述覆盖率 100%，五个参数（project、workdir、language、min_occurrences、max_candidate_length）都已有独立说明，描述只需做摘要。描述仅笼统提到「重复且一致」的概念，未补充 schema 之外的语义，符合覆盖率高的基线 3。

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?

明确了一个具体的动词和资源：读取游戏内已有译文并沉淀为翻译记忆。括号里的提示还划定了边界与术语类工具的差异（观察出来的对应不写进术语书），但未点出具体兄弟工具名称。

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?

使用场景只能从目的句中推断（想要从现有译文构建翻译记忆时用）。没有任何「何时用 / 何时不用」的说明，也没有与 scan、resource_term_candidates 等兄弟工具的取舍指引。

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 already declare destructiveHint=true; the description adds the important detail that this is an upsert keyed by aspect + scope, so an agent knows an existing entry with the same key will be overwritten rather than duplicated. It does not discuss permissions, priority effects, or return behavior, keeping it short of a 5.

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 single front-loaded sentence with zero filler, and the overwrite key is stated immediately. It is arguably too terse for a 7-parameter mutation tool, which caps it below 5.

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 mutation tool with 7 parameters and no output schema, the description covers the core action and key semantics but omits how optional params like priority, project, and workdir interact and what happens to non-keyed fields on overwrite. Annotations carry the destructive profile, so the remaining gap is moderate.

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 all 7 parameters are documented in the schema itself; baseline is 3. The description adds only the key-composition fact (aspect + scope), which is a small increment over what the schema already conveys.

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 pair (新增/覆盖 = add/overwrite) and resource (风格要求 / style requirement), plus the key composition (aspect + scope). It is clearly distinguishable from siblings like resource_style_list and resource_style_remove, though it does not name them explicitly.

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?

No guidance on when to use this vs resource_style_remove or resource_style_list, and no prerequisites stated. The upsert semantics are implied by 新增/覆盖 but the agent is left to infer the workflow.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no indication of scope, filtering behavior, or what a "first-class translation resource" implies operationally. The parenthetical is a classification label, not behavioral 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?

A single short phrase, front-loaded with the verb and free of padding. It is efficient, though the extreme brevity borders on under-specification rather than deliberate conciseness.

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 parameterless-required read tool with full schema coverage and annotations stating it is non-destructive, the essentials are covered. However, with no output schema and no description of what the listed style entries contain, an agent gets only a minimal picture of the 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?

Schema description coverage is 100% and both parameters (project, workdir) are self-documented with defaults, so the schema carries the burden. The description adds no parameter meaning, which is the expected baseline when coverage is complete.

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?

Contains a specific verb (列出/list) and resource (风格要求/style requirements), making it clear this enumerates style resources rather than mutating them. It does not explicitly contrast with the mutation siblings resource_style_add / resource_style_remove, so the differentiation comes only from the tool name.

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?

No when-to-use guidance, no prerequisites, and no mention of the add/remove siblings that share the same resource. The agent must infer that this is the read-side counterpart to resource_style_add and resource_style_remove.

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 already declare readOnlyHint=false and destructiveHint=true, so the mutation/destruction signal is covered by structured data. The description adds nothing beyond this - no note on idempotency, whether the operation is reversible, or what happens if the aspect does not match an existing requirement.

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 single short, front-loaded sentence with no filler. It is efficient, though the terseness contributes to the gaps noted elsewhere rather than being a virtue in itself.

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 destructive 4-parameter mutation tool with no output schema, the description should clarify how the target is identified and what the effect of removal is. None of that is present, leaving the definition incomplete despite the annotations covering the safety hint.

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 scope, aspect, project, and workdir. The description only hints that 'one' requirement is targeted, adding no syntax or format detail beyond the schema, 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 phrase '删掉一条风格要求' states a specific verb (delete) and resource (a style requirement), so the agent understands the operation. However, it does not differentiate itself from its obvious siblings resource_style_list and resource_style_add, so it falls short of a 5.

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 on when to use this tool versus resource_style_add/list, nor any prerequisites or exclusion conditions. The agent must infer usage entirely from the name.

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 declare readOnlyHint=false and destructiveHint=true, so the write nature is already structured. The description adds useful semantics about what a supplement entry represents, but it does not disclose what the 'destructive' aspect means for an add operation (e.g., whether it overrides an existing supplement or affects scan output), nor where the entry persists.

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 single front-loaded sentence: the action and the resource come first, followed by the clarification and examples in parentheses. No filler, no repetition of the schema.

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 a mutation tool carrying 8 parameters, the description covers the 'what' but not the effect: no word on persistence, whether the entry must be revalidated, or how it interacts with resource_supplement_list/remove and resource_validate. Adequate as a minimum, incomplete for a write tool in a family of similar resource_* tools.

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% (8 params, all documented, including defaults and the source/target distinction), so the schema does the heavy lifting. The description only clarifies the concept of the source text ('the runtime-looked-up string'), adding marginal value beyond what the schema already states.

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+resource ('declare/add a supplement entry') and clarifies the entry's purpose — text that must also be translated, with concrete examples (speaker names, UI strings embedded in code). However, it never distinguishes a 'supplement entry' from the sibling concepts resource_term_add or resource_style_add, so an agent cannot tell when this resource type is the right one to add.

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 phrase 'this text also needs translating' implies the context of use — supplementary strings not picked up by scanning — and the examples give a hint of the cases meant. But there is no explicit when/when-not, no prerequisites, and no pointer to the alternative tools (resource_term_add, resource_supplement_list/remove) the agent should consider.

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 already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds the semantic clarification that these are player-visible texts not enumerated by the engine, which is useful domain context. It does not describe output volume, ordering, or whether results are grouped by project/workdir.

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 single compact sentence with the conceptual clarification front-loaded inline. No waste, though the parenthetical could arguably be more explicit about the list's purpose.

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 zero-required-parameter read-only list tool with 100% schema coverage and no output schema, the description is minimally adequate. It explains the domain concept but leaves the agent without guidance on result shape, ordering, or relationship to resource_supplement_add/remove, which matters given 50+ sibling tools.

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% — both parameters ('project' and 'workdir') are documented in the schema, including the default workdir path. The description adds no parameter-level detail beyond what the schema provides. Baseline 3 applies since the schema does the heavy lifting.

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 (list) and resource (supplement entries), and adds a parenthetical clarifying what 'supplement' means ('text the engine does not enumerate but players see'). However, it does not distinguish this from sibling tools like resource_term_list or resource_style_list, which follow the same naming pattern. An agent must infer the distinction from the suffix alone.

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 on when to use this tool versus resource_supplement_add/remove or the other resource_*_list tools. The parenthetical explains what supplement entries are conceptually, but not the operational context in which listing them is appropriate.

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 already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond the annotation – it does not say whether deletion is reversible, whether it requires prior listing, or what happens if the source matches multiple entries.

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 single short sentence is front-loaded and wastes no words, but its brevity reflects under-specification rather than economy – there is no content to be concise about.

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 destructive, 3-parameter tool with no output schema and no annotations explaining consequences beyond the destructive flag, the description should at least note that the removed supplemental entry cannot be recovered and that 'source' must match an existing entry. None of that 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?

Schema description coverage is 100%, so all three parameters (source, project, workdir) are already documented in the schema. The description adds no syntax, format, or matching semantics (e.g., exact vs. fuzzy match on the source text), 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?

States a specific verb (删掉) and resource (补充条目), so the basic operation is discernible. However, it does not clarify what a 'supplement entry' is relative to its many siblings (resource_supplement_list, resource_supplement_add, resource_term_*), leaving the agent to infer scope.

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 indication of when to use this tool versus resource_supplement_add or resource_supplement_list, no prerequisites, and no mention of confirmation or irreversibility. The agent gets no routing guidance at all.

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 already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds some behavior beyond that: the row is written as provided and a new row is created when no match exists, hinting at whole-row overwrite/upsert semantics. It still omits auth needs, logging, merge behavior, and impact on existing fields.

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 single sentence is short but under-specified rather than concise. The bold label '人拍的板' is cryptic and the description is not front-loaded with an actionable purpose, making it hard to scan or reuse.

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 12-parameter, destructive, nested-object add tool with no output schema, one opaque sentence is far from complete. It omits how key/source/target/profile interact, the meaning of project/workdir defaults, position enum behavior, and how partial fills affect existing rows.

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 all 12 parameters. The description only echoes part of the 'exact' parameter and mentions five columns; it adds no syntax, examples, or interaction details beyond what the schema 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 is a cryptic operational note ('人拍的板：整行按给进来的那份写...') rather than a clear statement of purpose. It implies writing/creating a row, but never names the resource term table or distinguishes from siblings such as resource_term_propose, resource_term_import, or resource_term_remove.

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?

No when-to-use, prerequisites, or alternatives are provided. The clause '找不到同一行就新开一行' describes upsert behavior, not usage guidance, so an agent cannot tell when this tool should be chosen over sibling add/import/propose 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 destructiveHint=false/readOnlyHint=false given, the description adds real behavioral context beyond annotations: it discloses that it mutates existing translation names (queued for review), that new content is written unreviewed, and critically that it is idempotent ('重复调用不重复产行'). Idempotency is a key trait annotations do not convey.

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 single dense, front-loaded line with no filler; the core action leads and routing/idempotency details follow. The heavy parenthetical packs several facts but each 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?

No output schema exists, yet the description covers the return shape ('one entity per line') and the two side-effect paths plus idempotency. Combined with 100% schema coverage, this is largely complete for a mutation 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?

Schema description coverage is 100%, so all four parameters (project, workdir, language, min_scenes) are already documented in the schema, including the note that language is only recorded in the return. The description adds no parameter-level syntax or defaults beyond that 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+resource: '从场摘要抽实体' (extract entities from scene summaries), which is clearly distinct from siblings like resource_term_add or resource_harvest. An agent can identify what it produces, though the dense parenthetical bundles routing behavior that muddies the core purpose slightly.

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 explains the internal routing rules (new names/new facts appended unreviewed; changes to existing translations go to the pending queue), which implies usage context but never states when to call this vs alternatives like resource_harvest or resource_term_propose. No explicit exclusions or alternative-routing 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered structurally. The description adds real value by disclosing that '每一步都进变更日志' (every step is recorded in the change log), but it does not explain what happens to existing entries absent from the file or whether the change is reversible.

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 single front-loaded sentence with the bolded '整份换上' leading, so the core semantic is immediately visible. It is dense with em-dash clauses but no sentence is wasted; slightly crowded but effective.

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 destructive bulk-replace tool the description conveys the replacement semantics and change-log behavior, and the schema fully covers the parameters including dry_run. It still omits the disposition of removed/absent entries and any irreversibility warning, which matter for a destructiveHint=true operation.

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 all six parameters are documented in the schema (by/why/file/dry_run/project/workdir), so the baseline is 3. The description adds no parameter-level detail beyond noting the JSONL shape, which is already in the file param description.

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+resource: it makes the termbook end up exactly matching the given JSONL lines, explicitly covering splitting, merging, and batch renaming in one pass. This differentiates it from single-entry siblings like resource_term_add/resource_term_remove, though it never names a sibling outright.

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?

Usage is implied rather than stated: '整份换上' (whole replacement) and '一次做完' (all done in one shot) suggest this is the bulk alternative to doing splits/merges/renames individually. However, there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. resource_term_add), leaving routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by stating the return format (one entity per line with specific fields), though it does not mention pagination or sorting behavior.

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 single, front-loaded sentence states the core action and then clarifies the output format in a parenthetical. There is no redundant or wasted wording.

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 read-only list tool with full schema parameter coverage, the description explains the output shape well enough. It omits usage alternatives and pagination details, but no output schema exists, so the return format disclosure is helpful and largely sufficient.

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 all three parameters (hints, project, workdir) are fully documented in the schema. The description adds no parameter syntax, defaults, or format details 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?

States a specific verb (列出) and resource (术语书), and describes the output structure (one entity per line with key 写法列表 / profile 事实列表 / constant / order / position). It is clear, but does not differentiate from sibling tools like resource_term_pending_list or resource_term_candidates.

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?

No when-to-use, prerequisites, or alternative tools are mentioned. The name and description imply listing, but there is no explicit guidance on when to choose this over other resource_term_* list/manage 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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the destructive nature is known. The description adds value beyond that by specifying what is actually mutated (old replaced by new), that an audit entry is recorded, that the item leaves the queue, and that model identities are rejected - concrete behavioral context the annotations do not carry.

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 single dense sentence with the action bolded and front-loaded, followed immediately by the concrete effects. Every clause (swap, log, dequeue, identity restriction) earns its place with 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?

For a destructive one-shot mutation with annotations covering the safety profile and no output schema, the description covers effects, side effects, and an auth constraint adequately. It omits edge behavior (what happens on an unknown/already-adopted id, reversibility), which keeps it short of a 5.

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 100% schema description coverage, the schema already documents by/id/why/project/workdir individually. The description only loosely ties into these by mentioning the changelog (why) and the approval role, adding marginal meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (adopt/采用) applied to a specific resource (一条待审更正 - a pending correction) and enumerates the full effect chain: swap old for new, write a changelog entry, remove from queue. An agent can distinguish this from the sibling resource_term_pending_drop, which discards rather than applies the proposal.

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 parenthetical '(模型身份会被拒)' signals a real precondition - the caller identity matters and model/agent identities are refused - which is genuine usage guidance. However it never says when to prefer this over resource_term_pending_drop or how to handle the rejected-identity path, so guidance is implied rather than explicit.

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 already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description still adds real value by clarifying the blast radius: the change is rejected from the queue but the underlying book/resource is left untouched, which meaningfully narrows what 'destructive' means here.

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 single front-loaded sentence with a tight parenthetical that clarifies scope. Every element earns its place with zero 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 low-complexity, single-required-param mutation, the description plus annotations plus fully documented schema cover what an agent needs. It could be slightly stronger by naming the adopt sibling as the alternative path, but nothing essential 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 description coverage is 100% (id, project, workdir all documented), so the schema carries the parameter burden. The description adds no additional syntax or format meaning beyond what the schema provides, making the baseline 3 correct.

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 (丢弃/discard) and resource (待审更正/pending correction), and adds the crucial scope qualifier that it does not modify the book, only removes the queue entry. It distinguishes itself from the other pending tools (list/adopt) by effect, though it does not name them explicitly.

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?

Usage is implied: call it to discard a pending correction from the queue. However, it gives no explicit when-to-use guidance and does not contrast with the obvious sibling alternative (resource_term_pending_adopt), leaving the drop-vs-adopt 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds genuinely useful context: nothing in the book changes until adoption ('采用之前书里一个字节都不动'). This clarifies the semantics of 'pending' beyond the safety flags. It does not describe return contents or ordering.

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 single sentence, front-loaded with the core action and scope, with the em-dash clause carrying the behavioral note. Little waste, though the compound structure is slightly cryptic.

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 list tool whose annotations carry the safety profile, the description is adequate but thin. With no output schema, it still does not indicate what the listing returns, so an agent must infer the shape of results.

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 project/workdir/writing are already documented in the schema. The description contributes no additional filter syntax or semantics, 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?

States a clear verb (列出 = list) and resource (待审更正 = pending corrections), and the parenthetical sharpens the scope to corrections of existing terms/facts rather than new entries. This distinguishes it from the add/propose siblings without naming them. It stops short of explicitly contrasting with resource_term_pending_adopt/drop.

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?

Usage is only implied: an agent infers this is the tool to call to review proposals before adopting or dropping them. No explicit when/when-not guidance or named alternatives (e.g. pending_adopt, pending_drop) are given.

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 declare destructiveHint=true and readOnlyHint=false, so the safety profile is already covered. The description adds genuinely new behavior: the correction is queued and is not effective until adopted – useful context that annotations cannot express. It stops short of describing auth/limits or what the queued entry looks like.

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 single, front-loaded line that states the action, its scope and its deferred-effect semantics with zero filler. Nothing to trim.

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 7-parameter mutation tool with no output schema, the description plus full-coverage schema cover the essentials, and the queuing behavior is disclosed. It could still say more about the result of a successful proposal or the project/workdir defaults, but nothing critical 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 description coverage is 100%, so all seven parameters are already documented, including the key/profile enum. The description only echoes the 'change existing translation/fact' framing and adds no syntax or format detail beyond the schema – 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?

Names a specific action (提一条更正) with an explicit scope – correcting an existing 译名 or 事实 – which separates it from resource_term_add (new terms) and the pending/adopt workflow. The purpose is clear, though it never names the actual sibling tools it routes between.

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?

States the usage context (amend an existing translation/fact) and the key precondition that the change queues first and only takes effect on adoption, which implies the follow-up step. No explicit exclusions or named alternatives (e.g. resource_term_remove / pending_adopt) are given.

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 already declare destructiveHint=true and readOnlyHint=false. The description adds only '按任一写法', which is also in the source parameter schema and does not describe irreversibility, matching behavior, or effects on references.

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?

Single front-loaded sentence with no filler, but it is too terse for a destructive multi-parameter tool; conciseness here comes at the cost of completeness.

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?

Incomplete for a destructive resource mutation: it does not clarify what a resource term is, deletion scope, or side effects. Annotations and schema cover some safety and parameter detail, but the description leaves the agent with insufficient context to call confidently.

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 description's '按任一写法' mirrors the source parameter description and adds no syntax or matching details 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?

States a specific action (删除一行) but does not name the resource or domain; 'row' is ambiguous in a glossary/termbase context. It distinguishes from add/list siblings only by verb, not by scope.

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 no when-to-use guidance, prerequisites, or alternatives. It does not route the agent among resource_term_pending_drop, resource_term_import, or other sibling 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that invalid lines are listed (an output behavior), but says nothing about what counts as invalid, whether it mutates state, or how results are surfaced.

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 single terse clause, front-loaded with the verb and result. It wastes no words, though it is arguably too sparse to be maximally useful for a multi-parameter 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?

For a read-only validator with two optional, fully documented parameters this is minimally adequate. There is no output schema, so the brief mention of listing invalid lines is the only return-value hint, and the validation scope/criteria remain unstated.

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 parameters (project, workdir) carry their own defaults and descriptions, so the schema does the heavy lifting. The description adds no parameter meaning beyond that, which is the baseline 3 case.

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 (校验/validate) and resource (资源文件/resource files) plus the outcome (列出非法行/list invalid lines), so an agent knows what the tool produces. However, it gives no differentiation from validation-adjacent siblings such as revalidate, and '资源文件' is not scoped to a particular resource 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?

No guidance on when to run this versus alternatives like revalidate, resource_harvest, or scan, and no prerequisite or context is given. The agent must infer usage entirely from the name.

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 already declare readOnlyHint=false and destructiveHint=true, so the write/destructive nature is conveyed structurally. The description adds genuine context beyond that – the one-directional constraint '只放行，不收紧' (only releases, never tightens) – but it does not say what state is overwritten or which records are touched.

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 single front-loaded sentence with no filler; the core action and its directional constraint are packed into one clause with zero waste.

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 state-mutating tool with no output schema, the description covers the action and its one-way behavior but omits what the re-adjudication actually changes (status fields, writeback, block records) and what the agent should expect afterwards, leaving a meaningful 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%, so both parameters (project, workdir) are already fully documented in the schema. The description adds no additional meaning about parameters, 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 states a specific verb+resource: re-adjudicating previously blocked translations under current criteria. It is clear what the tool does, but it does not name or differentiate itself from any sibling (e.g. resource_validate, translate), leaving the agent to infer the boundary.

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?

Usage is only implied: you would reach for this after criteria have changed and you want previously blocked items reconsidered. There is no explicit when-to-use/when-not statement and no alternative tool named for related re-validation work.

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 declare readOnlyHint=false and destructiveHint=true, yet the description reads like a read/extract-and-generate operation and never discloses what is written, overwritten, or destroyed, or whether the scan mutates project state. For a destructive tool with zero annotation-level explanation of blast radius, the description leaves the key behavioral risk unaddressed.

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 single compact clause with the two outputs front-loaded and no filler. It is efficient, though for a destructive tool the terseness edges toward under-specification rather than pure conciseness.

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 destructive annotations and no output schema, the description should explain what the scan writes or changes and what '待译内容' / '带权路径图' actually contain. It instead stops at a high-level label, leaving the mutating behavior and result shape opaque for a state-changing 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?

Both parameters (project, workdir) are fully documented in the schema with defaults, so the schema carries the semantics. The description adds no syntax, format, or interaction detail about project/workdir beyond what the schema already states, which is the expected baseline at 100% 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 names a concrete verb pair and two outputs: '提取全部待译内容' (extract all pending-translation content) and '产出带权路径图' (produce a weighted path graph). That is specific enough for an agent to know roughly what it returns, but it gives no differentiation from closely related siblings such as graph_show, plan, or translate.

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 indication of when this tool should be invoked versus alternatives (e.g., graph_show, plan, staleness). The only usage cue is the implicit 'pending翻译内容' scope; no prerequisites, triggers, or exclusions are stated.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the output is a report of counts and distributions, which is mild useful context, but it discloses nothing about auth, cost, or error behavior beyond that.

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 single compact sentence with the resource front-loaded and the reported contents enumerated in parentheses, which is exactly the shape of value-dense reporting.

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 read-only inspection tool with full schema coverage and no output schema, the parenthetical enumeration of what the report contains partly substitutes for a return-value spec. Nothing critical for invoking it correctly 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 description coverage is 100%: project, workdir, and language are each documented in the schema with defaults and fallback behavior. The description adds no parameter-level detail, 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?

States a concrete verb (view) and resource (engine-generated skeleton) and enumerates the reported contents: slot count, distribution of the two key-setting methods, per-file split. It does not distinguish itself from sibling status tools such as project_status or agent_status, so an agent gets the resource but no disambiguation.

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 when-to-use guidance: nothing says to call this after generating a skeleton, before packing, or instead of sibling inspection tools like scan or plan. Usage is only inferable from the name and the 'engine-generated skeleton' phrasing.

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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that the tool separates stale, missing, and unavailable translations and is the precise path after knowledge changes. It does not describe return shape, permissions, or side effects, leaving moderate value beyond structured fields.

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?

One compact sentence with a parenthetical qualifier. The core action is front-loaded with zero filler, though the compressed phrasing is slightly terse.

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, so the description should carry more of the return-value burden. It names the report categories but does not specify the output shape (e.g., list of keys, counts) or ordering, leaving an agent with some uncertainty about what a call actually returns.

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 parameters (project, workdir) are fully described in the schema. The tool description adds no parameter meaning, so 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?

States a specific verb (点名/call out) and resource (该重做的译文/translations needing redo), and breaks the report into three named categories (过期/缺失/不可用). It also hints at the triggering condition (知识改了/knowledge changed) to differentiate from sibling reporting tools, though it does not name a sibling directly.

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 ties usage to a condition: when knowledge has changed, use this for precise replenishment. No when-not-to-use or named alternatives are given, but the triggering context is clear and actionable.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that passing ref returns the complete payload including retrieval/results, which is useful behavioral color. It doesn't discuss pagination, ordering, or what absent refs return, so it only modestly exceeds the annotations.

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 tight clauses with no filler, front-loading the core action and then the ref conditional. Minor friction: it uses CLI-style '--ref' while the actual parameter is 'ref', which could momentarily confuse an agent invoking via JSON.

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 read-only listing/lookup tool with 100% schema coverage and no output schema required, the description covers the essential distinction between listing and single-record retrieval. Nothing critical for correct invocation 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 description coverage is 100%, so all five parameters are already documented in the schema, establishing a baseline of 3. The description reinforces the 'ref' semantics (full payload with retrieval results) but adds nothing for limit, status, project, or workdir beyond what the schema states.

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?

It states a specific verb and resource: '查看持久化的翻译任务状态' (view persisted translation task status), which distinguishes it from generic siblings. However, the name 'tasks' is broad and the description doesn't explicitly contrast it with similar status tools like agent_status or project_status. Purpose is clear but sibling differentiation is only implicit.

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 a conditional on the 'ref' parameter ('给 --ref 则看某一条的完整载荷'), which hints at when to pass ref versus listing all. But there is no guidance on when to choose this tool over the many sibling status/list tools, and no exclusions or prerequisites. Usage is implied rather than directed.

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 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.

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.

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.

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.

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.

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.

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

Annotations supply the safety profile (readOnlyHint=false, destructiveHint=true), and the description adds the useful nuance that the message goes 'directly' to the user from the agent identity. However, it does not explain why an announce tool is destructive, whether the message persists, or how severity affects delivery, leaving the destructive hint uncontextualized.

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 single, front-loaded sentence with no filler. It is efficient, though being this terse is also the source of the missing usage and behavioral detail.

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 4-parameter tool with no output schema, the 100%-covered schema and present annotations carry most of the load, but the description is silent on severity semantics, persistence, and the unexpected destructive classification. Adequate but with clear gaps.

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 message, project, workdir, and the severity enum are already documented in the schema. The description adds nothing beyond this baseline, which is the correct default when the schema fully documents the 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?

States a specific verb (发布/publish) with a clear resource (一条信息/a message), recipient (用户/user) and identity (以 agent 身份). It is distinguishable from UI siblings like ui_render and ui_views, though it never explicitly contrasts itself with them.

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 offers no when-to-use or when-not-to-use guidance and does not name any alternative among the many ui_*/agent_* siblings. The agent must infer that this is for user-facing notifications versus rendered views or status 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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the destructive profile is covered. The description adds one genuinely useful behavioral fact beyond that: pinned views are preserved, only non-pinned ones are removed. It says nothing about reversibility, whether state can be recovered, or what the call returns.

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 single short sentence with the scope constraint front-loaded and no filler. It is appropriately sized for the operation, though it is terse to the point of leaving meaningful behavior unstated.

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?

Annotations carry the destructive flag and the schema fully documents both params, which lowers the burden. Still, a destructive state-mutating tool with no output schema should at least state the effect scope and whether cleared views can be restored; that gap keeps this at a minimum-viable 3.

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 only two optional parameters (project, workdir), both fully documented in the schema. The description adds no parameter meaning of its own, 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?

States a specific verb+resource ('清掉...视图' / clear views) with a scope qualifier ('非置顶的' / non-pinned), so an agent knows exactly what is removed. It does not, however, differentiate itself from siblings such as ui_hide or ui_views, which also operate on views, so sibling disambiguation is left to inference.

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 on when to call this versus ui_hide (hide a specific view), ui_views (list views), or ui_override. The 'non-pinned' clause hints at scope but is not framed as a use condition or exclusion.

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 already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered by structured data. The description adds one piece of behavioral context: the operation is dual-mode and reversible ('或恢复'), which softens the destructive framing. It does not state scope (per-user vs project-wide), persistence, or side effects.

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 single compact clause, front-loaded with the primary action and parenthetically covering the inverse. No waste, but its brevity borders on under-specification rather than deliberate tightness.

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 4-parameter mutation tool with no output schema, the description omits the essentials: default behavior when 'unhide' is omitted, whether hiding is reversible beyond the unhide flag, and how the target view is identified. Annotations only cover the read/write axis.

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%: 'unhide' is documented as '改成恢复显示', and project/workdir/view_id all carry their own descriptions. The description adds nothing beyond the schema, 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?

States a specific verb+resource pair ('对用户隐藏...一条视图') and even covers the inverse mode (恢复). However, it gives no differentiation from close siblings such as ui_clear, ui_override, or ui_views, so the agent must guess which UI mutation tool applies.

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 when-to-use or when-not-to-use guidance, and no mention of the alternatives (ui_clear, ui_override, ui_views). The agent cannot tell from the description whether hiding is a soft, reversible suppression or a hard removal like ui_clear.

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 already declare destructiveHint=true and readOnlyHint=false, consistent with 'rewrite'. The description adds nothing beyond that: it does not say whether the previous view content is discarded, whether the view must already exist, or what happens to unset fields. No contradiction, but also no added behavioral context.

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