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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the offline JSON mutation, the exact keys modified (TaskDefinitions/TaskEnabledList/TaskOrder), that daily automation content will change, the confirm=true gate, and that a backup is auto-created.

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 paragraph that front-loads the action, then the mechanism, then the safety warning. Every clause carries information; nothing is padding.

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 no annotations and no output schema, it discloses the risk profile, backup behavior, and file mechanics well. It does not describe the return value or how failures surface, leaving a small 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 every parameter is already documented in the schema, making 3 the baseline. The description reinforces the confirm requirement and file target but adds no syntax detail 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?

States a specific verb and resource (add a config group into the OneDragon daily flow) and even names the underlying file and keys it touches, so an agent understands exactly what happens. It does not explicitly differentiate from similar siblings like bgi_set_onedragon or bgi_create_onedragon, keeping it at 4.

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

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

Gives clear context for when to use it (connecting a group into the daily automation) and reveals the important precondition that confirm=true is required to write. It does not mention when to prefer an alternative sibling tool or any exclusions.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses graceful versus forced shutdown, the config-overwrite risk if BetterGI keeps running, the admin-privilege limitation, and the confirm/dry_run safety gate. It also states that the tool reports whether the process was actually closed, which is important behavioral context for a destructive operation.

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

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

The description is dense but front-loaded: purpose comes first, followed by the config-overwrite warning, permission caveat, and confirm/dry_run requirement. No sentence is expendable, though the bolded parenthetical formatting makes it slightly heavier than necessary.

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 no annotations, so the description must carry safety, permission, and reporting context; it does all of that. Given the tool's destructive potential and the four-parameter schema, the definition supplies everything an agent needs to decide whether and how to call it.

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

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

Schema coverage is 100%, so the schema already documents all four parameters. The description adds useful semantic context by linking force to 'necessary' escalation, confirming that confirm:true is required for actual closure, and presenting dry_run as the preview mode, though it does not elaborate on the target enum 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 precise verb and resource: close Genshin Impact / BetterGI, with graceful-then-force behavior and truthful reporting. It also scopes the target set (game vs BetterGI vs both), which clearly distinguishes it from siblings like bgi_status, bgi_start_game, and bgi_focus_game.

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 an explicit usage condition: BetterGI must exit before modifying User\config.json or User\OneDragon\*.json because it may overwrite the file while running. It also states the confirm/dry_run requirement and notes the admin-permission alternative path, though it does not explicitly name sibling tools for checking status first.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses the discrete side effects (filesystem write to User\AutoPathing, group creation named 采集-<材料>, and conditional task execution). It stops short of covering failure behavior when a material has no route, permission/auth needs, or whether an existing group is overwritten.

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 arrow-chained sentence that front-loads the tool's identity and then walks the pipeline in execution order. Every clause maps to a distinct step; 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?

For a composite, side-effecting tool with no annotations and no output schema, the description gives enough of the pipeline for an agent to call it correctly. Gaps remain around return values (does it report the group name or route path?) and error paths when no route exists, but the core behavior is covered.

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

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

Schema coverage is 100%, so the schema already documents all four parameters including defaults and examples (星螺). The description only restates the run=true behavior ('立即触发执行'), which the schema parameter description already conveys, so it adds little beyond the structured fields.

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 (采集材料) and enumerates the internal workflow steps: repo route lookup, conditional download to User\AutoPathing, config group creation, and optional execution. The 'flagship tool' label signals it is the composite entry point, but no sibling tool is named outright (e.g. vs bgi_collect_now or bgi_create_group), so differentiation 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?

Usage context is implied via '一键' and the run=true branch, and the schema note '先给用户确认' hints at a confirm-before-execute workflow. However, the description never states when to prefer this over sibling tools like bgi_collect_now, bgi_find_routes, or bgi_create_group, nor any preconditions.

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

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

With no annotations, the description carries the full burden and does well: it discloses that it actually launches BetterGI and takes over game input, that confirm=true is mandatory to fire, that dry_run only prepares, and that it will attempt to restore/minimize-and-foreground the game window. It omits failure/timeout behavior for the milestone polling, which keeps it from 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?

Despite being one long sentence with arrow separators, the flow is front-loaded with the core purpose and the side-effect/confirm caveat comes last. Little wasted text; only the redundant dry_run restatement could be trimmed.

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 mutating orchestration tool with no annotations and no output schema, the description covers the critical gaps: side effects on the game, the confirm gate, the dry-run escape hatch, and window-state prerequisites. Missing only what the milestone poll returns or how long it waits before giving up.

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 five parameters (force, confirm, dry_run, material, overwrite) are already documented with semantics including the <1080p warning. The description only echoes confirm and dry_run, adding no format, defaults, or interaction rules beyond the schema — 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?

The description gives a concrete verb chain (ensure route/config group → prepare window → trigger config group → poll to milestone) rather than restating the name, so an agent knows this is an end-to-end 'one-shot' collector. It never names a sibling (e.g. bgi_collect_material, bgi_run_groups) to contrast with, so differentiation is only implied by '一步到位入口'.

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 context is implied ('说一句就采集' one-step entry) and the confirm=true gate plus dry_run preparation mode are stated, giving some when-to-use signal. There are no explicit exclusions or named alternatives — nothing tells the agent why it would pick this over bgi_collect_material or bgi_run_groups.

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

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

With no annotations, the description carries the full burden, and it does disclose the important non-obvious trait that existing groups are appended to rather than overwritten. However it says nothing about what happens on duplicate targets, whether writes are persisted/undoable, or the failure mode when a name collides.

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

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

Two short sentences, zero filler, with the upsert behavior and the trickiest parameter convention both front-loaded.

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

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

There is no output schema and no annotations, so the description is the only behavioral source; it covers the main pitfall (target path format) but omits what the call returns and how the type/folder parameters affect target interpretation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds value by specifying the target path syntax for Pathing ('子目录/文件名.json' or '文件名'), a convention the schema does not state. It leaves the non-Pathing target formats and the folder/type interaction unmentioned.

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 plus non-obvious upsert semantics ('新建或向既有配置组追加项目'), so an agent knows this both creates and appends rather than only creating. It does not explicitly differentiate itself from the sibling bgi_add_group_to_onedragon, which also manipulates group membership.

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 create-or-append wording implies when the tool applies, but there are no explicit conditions, prerequisites, or named alternatives. An agent must infer from experience whether to use this versus bgi_add_group_to_onedragon or bgi_run_groups.

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

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

With no annotations, the description carries the full burden and does well: it discloses the key write-time invariant (filename and JSON Name field are forced to the same value), the duplicate-name rejection and why it exists (BetterGI otherwise matches one at random), and the Ordinal exact-match behavior of startOneDragon. It stops short of describing permissions or what the tool 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?

Two sentences, front-loaded with the action, then a clearly marked caveat about name matching. Dense but every clause carries operational information; 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 mutation tool with no annotations and no output schema, the description covers what is created, the naming invariant, and duplicate handling — the parts an agent could get wrong. It omits success/return behavior and environment prerequisites, which is a modest 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 the baseline is 3, and the description genuinely adds meaning: it explains that `config` becomes both filename and Name field and that the CLI matches by the JSON Name with Ordinal comparison — runtime semantics the schema's one-line description does not convey. The `from` default and `overwrite`/`dry_run` behavior remain in the schema rather than the 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?

States a specific verb and resource (新建「一条龙」配置) plus the two creation modes (copy an existing config or start from an empty template) and optional task ordering. It does not explicitly contrast itself with the sibling bgi_set_onedragon or bgi_add_group_to_onedragon, so sibling differentiation is left 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?

The creation scenario is clear, but the description never states when to prefer this over bgi_set_onedragon (modify) or bgi_add_group_to_onedragon, nor does it mention prerequisites such as BetterGI needing to be running. Usage is implied rather than prescribed.

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?

在没有注解的情况下，这句描述通过声明该工具只读、不会启动任何进程，承担了大部分职责——这正是 agent 在担心卡住游戏或触发运行时所需要知道的。它还披露了一个不明显的安全细节：缺失的 Pathing 条目会被静默跳过，这正是要事先检查的原因。缺的是它预期运行多久，以及它报告的结果是什么形态。

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 的只读诊断工具来说，描述已经足够完整：它说明了何时调用、是否安全、覆盖哪些内容，以及哪些检查结果会被静默忽略。唯一真正的遗漏是没有描述它返回的判定结果，而 agent 会希望知道这一点，以便据此分支处理。

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

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

唯一一个可选参数（material）在 schema 中已有完整说明（100% 覆盖率），因此 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?

开头就断言一个具体动作——开跑前体检，并立即限定范围（只读、不启动任何进程），随后逐一列出检查覆盖的内容（安装、窗口就绪、DPI、路径资产、配置组中的 Pathing 文件、一条龙配置、MCP 封装）。一个 agent 不必打开其他工具就能知道 bgi_doctor 与 bgi_status 或 bgi_run_* 在操作特性上的区别。

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?

"跑采集或秘境前先调它" 明确给出了调用时机，而且非常可操作。但它没有说明何时可以安全跳过，也没有点名替代工具（例如 bgi_status），因此实际使用时 agent 必须自行推断边界情况。

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

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

With no annotations, the description carries the full burden. It usefully discloses the one real side effect — files are written to User\AutoPathing only when download=true — but says nothing about overwrite semantics (overwrite=true can clobber existing files), behavior when no material matches, or result ordering/limits.

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 sentences: purpose and repository location first, then the illustrative example, then the download side effect. No filler, and the most decision-relevant fact is front-loaded.

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

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

For a 4-parameter, annotation-free, no-output-schema tool, the description covers purpose, source repo, example result shape ('5 routes'), and the download destination. It is only slightly short on failure behavior and on how results differ from the sibling listing 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 coverage is 100%, so the baseline is 3; the description goes slightly beyond by adding the concrete download destination path (User\AutoPathing) and a sample material value, which the schema does not state. The kind enum and overwrite flag are still left entirely to 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 verb and resource: search map-tracking routes in the named official repo (babalae/bettergi-scripts-list), with a concrete example ('星螺' → 5 Liyue routes). It does not explicitly distinguish itself from the close sibling bgi_list_pathing or bgi_repo_index, leaving the agent to infer the difference between searching the remote repo vs. listing local content.

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?

Implies a search-then-optionally-download workflow ('download=true 时下载到 User\AutoPathing'), which is useful context. But there is no explicit when-to-use vs. bgi_list_pathing / bgi_install_js guidance and no stated preconditions or exclusions.

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

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

With no annotations, the description carries the full burden and does well: it explicitly warns '会改变你当前焦点', discloses the side effect of restoring from minimized and stealing focus, and states the precondition that automation will fail or pause if requirements aren't met. It doesn't cover failure modes (e.g., what happens if the window isn't found), keeping it at 4.

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

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

Two sentences, front-loaded with the action and the focus-change warning, followed by the requirement rationale. No filler, though the requirement criteria are slightly dense.

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

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

For a one-parameter, no-output-schema tool, the description covers action, side effects, and even the reported values (client size, aspect ratio, resolution, foreground status) plus success criteria. It's essentially complete; only the absence of sibling disambiguation is a minor 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 the single parameter no_focus is already fully documented in the schema. The description does not reference the no_focus option at all, so it adds nothing beyond the schema for parameters; 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 action (restore the Genshin window from minimized and try to bring it to the foreground) plus the diagnostics it reports (client area size, 16:9, ≥1080P, foreground status). An agent can tell this is a window-preparation step rather than a launch/run tool. It stops short of naming a sibling to contrast with, so it lands at 4.

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 clearly states the context of use: '跑自动化前的窗口准备' and that collection/domain runs require '可见 + 前台 + 16:9 ≥1920×1080' or automation fails/pauses. It gives clear when-to-use context but no explicit 'do not use this, use X instead' alternative.

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

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

No annotations are provided, but the description discloses the key behavioral trait: this is a filesystem write that copies an entire directory into a fixed path, and it names the concrete artifacts written. It omits failure behavior when the directory already exists, whether network access to the official repo is required, and what is returned on success or partial failure.

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

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

Two compact sentences: the first defines the action, source, destination and payload; the second routes to the follow-up tools. Nothing is redundant and the core operation is front-loaded.

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

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

For a write tool with no annotations and no output schema, the description covers source, destination, contents and next steps — enough to invoke it correctly. The remaining gap is error/overwrite semantics and return information, which are only partially covered by the schema's `overwrite` field.

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 `name` (directory under repo js/, e.g. AutoCommission) and `overwrite` (default false) are already documented in the schema. The description only reinforces that `name` becomes the destination folder name; baseline 3 applies since the schema carries the parameter detail.

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 (install) and resource (a whole JS script directory from the official repo) plus the exact destination path User\JsScript\<name>\ and what gets installed (manifest.json, main.js, resources). It also names the sibling tools (bgi_run_js, bgi_add_group_to_onedragon) that follow it, so the agent can place it in a workflow without opening a schema.

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

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

Gives clear downstream context: after installing, use bgi_run_js to create/run a group or bgi_add_group_to_onedragon for the daily pipeline. It does not state prerequisites such as where the valid `name` comes from (e.g., bgi_list_js_scripts / bgi_repo_index) or when not to call it (already installed without overwrite).

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

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

With no annotations, the description carries the burden and does well: it discloses that writes are validated against settings.json's schema (select values must be within options, checkbox coerced to boolean) and that the config group is automatically backed up. It stops short of stating permissions needed, failure behavior, or what a listing returns structurally.

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 dense sentences with the storage-location caveat front-loaded and the read/write split following immediately; no filler. The parenthetical em-dash aside is long but it encodes the most important non-obvious fact.

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 2-parameter tool with no output schema and no annotations, the description covers storage location, both operating modes, validation rules, and backup behavior — enough to call it correctly. Minor gaps remain around return shape for the listing mode and error handling.

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 both parameters are already documented, establishing a baseline of 3. The description does add useful semantics — 'set' absent means read, present means write with validation, and 'name' equals both the script directory and the config group name — but the schema already conveys most of this.

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 and resource ('读写官方 JS 脚本的设置') and immediately clarifies a surprising storage detail (settings live in the config group's jsScriptSettingsObject, not on disk), which separates it from disk-oriented siblings like bgi_list_js_scripts or bgi_install_js. It does not, however, name any sibling explicitly to route the agent.

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

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

The two modes are spelled out clearly: omit 'set' to enumerate all configurable items and current values, include 'set' to validate-then-write. That is a clear use condition tied to the parameter, but there is no mention of when to prefer bgi_set_config or which scripts qualify as 'official'.

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

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

No annotations are provided, so the description carries the full burden. '列出' implies a read-only enumeration, but the description never states that it has no side effects, whether results are cached or fetched live, or whether the list can be empty or large.

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 waste. The resource and the returned fields are front-loaded, and there is no restatement of the tool name.

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-parameter read tool, the description covers the purpose and sketches the return shape (name/type/status), which matters because no output schema exists. Minor gaps remain: no mention of ordering, emptiness, or how 'items' relate to strategies or one-dragons.

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?

There are zero parameters, so the baseline is 4. The description goes slightly beyond the schema by stating what each listed item contains (name/type/status), which is useful since it has no output 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?

It states a specific verb and resource: 'list all configuration groups and their items', and even hints at the contents (name/type/status). The 'all' signals no filtering, which separates it from bgi_create_group or bgi_run_groups by intent, though the description 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?

Usage is only implied: an agent can infer 'call this to enumerate configured groups before creating or running one', but the description gives no explicit when-to-use, prerequisites, or alternative such as a filtered sibling like bgi_list_strategies.

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

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

With no annotations, the description carries the full load: it discloses scope (js/ partition), a snapshot count and date, and that detail mode performs an extra manifest fetch. It does not say whether the listing is fetched remotely or read locally, how long it takes, or what the manifest lookup does on failure — meaningful gaps for an unannotated 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?

Short and front-loaded: what it lists first, then the detail behavior. The parenthetical example list is somewhat long but doubles as keyword hints for the filter parameter, so it mostly 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 and no annotations, so the description must explain return shape — it only gets partway (names plus examples; manifest fields name/description/version in detail mode). It omits whether entries include paths, sizes, or categories, and leaves the detail-parameter typing ambiguous.

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 baseline would be 3, but the description actively misdescribes the detail parameter: it says 'detail=true 时会拉该脚本的 manifest.json' (implies a boolean) while the schema declares detail as a string holding a script directory name. This could mislead an agent into passing "true" and getting nothing back. The filter explanation ('keyword such as 委托/树脂/纪行') is a modest useful addition.

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 JS scripts from the official repo's js/ section, with concrete examples (AutoCommission, AutoRefinedCondensationResin) and a real count (144 as of 2026-10-16). It is distinguishable from listing siblings like bgi_list_pathing or bgi_list_strategies, though it never explicitly contrasts with the run/install tools that consume these scripts.

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 can infer this is the discovery step before bgi_run_js or bgi_install_js, but no sentence says 'use this before running/installing a script' or when to prefer bgi_repo_index instead. No exclusions or prerequisites 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?

No annotations are provided, so the description carries the burden. It clearly describes a read-only listing of local files and the glob it scans, which implies no mutation, but it does not state whether scanning has side effects, how large results may be, or what the response 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 compact sentence that front-loads the action and resource, then gives the file scope and filtering behavior. No wasted text.

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 fully described parameters and no output schema, the description covers what is listed, where it comes from, and the optional filter. It could add a brief note on result ordering or limits, 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 coverage is 100%, so the schema already documents both 'filter' and 'extra_dirs'. The description adds meaning for the filter ('只看名字含该关键词的路径'), but does not mention 'extra_dirs', leaving that parameter to 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 verb ('列出') and resource ('本机已安装的地图追踪路径'), plus the exact file glob ('User\AutoPathing\**\*.json'), so the agent knows what is listed. It does not explicitly distinguish itself from the sibling bgi_find_routes, which could overlap semantically.

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?

Mentions the optional keyword filter ('可按关键词过滤'), implying how to narrow results, but gives no guidance on when to use this tool versus bgi_find_routes or other list/route tools. 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?

No annotations are provided, so the description carries the full burden. It does disclose the underlying filesystem scope and that a prediction mode exists, which is real behavioral value, but it says nothing about read-only safety guarantees, how prediction is computed, or behavior on missing directories/empty teams.

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 primary listing behavior front-loaded and the optional prediction mentioned after it. Nothing 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?

There is no output schema, so the description should say what is returned (file names? paths? and what the prediction produces). It stops short of describing return shape or ordering, leaving an agent to guess the response format.

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 already gives a comma-separated example, so the baseline is 3. The description adds meaning beyond the schema by explaining that providing team activates a prediction of which strategy the auto-select rule would choose, which the schema text alone does not convey.

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?

Concrete verb + resource: it lists local battle strategy files and states the exact glob (User\AutoFight\**\*.txt), plus an optional prediction mode. The resource is specific enough to separate it from siblings like bgi_list_groups or bgi_list_js_scripts, though no sibling is named 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?

It gives clear usage context: call it to enumerate strategies, and supply a team when you want to know which one auto-select would pick. There is no explicit when-not guidance or pointer to an alternative tool.

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

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

No annotations are supplied, so the description carries the burden, and it does disclose the key constraints: scope is limited to 当天 (today's) logs, and results carry line numbers, timestamps, class names and message bodies. It does not state whether logs rotate, whether there are size limits, or whether reading is entirely side-effect free, but the essential behavioral shape is given.

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

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

Two sentences, front-loaded with the tool's identity and scope; the parenthetical and the bgi_status comparison both carry real information. Slightly dense prose style, 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 annotations and no output schema, the description compensates by describing the return shape (line number, timestamp, class, message) and the day-scoped limitation. Adequate for correct invocation, though limit/truncation behavior on very large logs is 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%, so each parameter is already documented. The description restates the filter dimensions (级别/正则/时间窗/任务关键字) and maps them to params like levels, pattern, since_minutes and task, but adds no syntax, defaults or format detail 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?

A specific verb and resource: 定向检索 inside 当天 BetterGI 日志, with the use case (诊断"为什么失败"的取证工具) stated up front. The final clause explicitly contrasts it with sibling bgi_status's log tail, so an agent can choose between the two without opening either schema.

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

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

It states the context for use (forensic diagnosis of why something failed) and names the weaker alternative, which implicitly says when to prefer this tool. It doesn't state explicit exclusions or prerequisite conditions, so it stops just short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only directory listing and signals the output is a tree (目录树), but it says nothing about whether the browse is safe, whether it hits network/rate limits, or how 'limit' truncates the tree.

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 purpose comes first and the discovery hint follows immediately. It is arguably too terse given the tool has three parameters, 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?

For a low-complexity, zero-required-parameter browse tool with a fully documented schema, the definition is adequate but thin: it never explains the shape of the returned tree or how kind partitions interact with the default pathing partition, and no output schema exists to cover that 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 kind, limit, and filter are already fully documented with defaults, and one parameter is an enum. The description adds no syntax or semantics beyond that, which is the expected baseline when the schema does the 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?

Names a specific action and resource — browsing the official script repository tree — and scopes it to discovering routes, JS scripts, and combat strategies. It does not distinguish itself from close siblings like bgi_list_pathing, bgi_list_js_scripts, or bgi_list_strategies, leaving the agent unsure which to pick when it wants a specific category.

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 '用于发现可用的...' implies a discovery use case, which is helpful context, but there is no statement of when NOT to use it and no named alternative such as bgi_find_routes for targeted search. Usage is implied rather than prescribed.

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

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

No annotations exist, so the description carries the full burden, and it does disclose the key traits: it is read-only (只读) and it reveals the data-availability gotcha that one-dragon runs leave no execution records. It omits retention/emptiness behavior when no records exist and any return-format detail, keeping it short of the top score.

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 output content is front-loaded in a single dense clause, followed by a clearly marked 注意 caveat. No sentence is redundant, and the high-value warning sits at the end where it is easy to scan.

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

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

With no output schema and no annotations, the description does the necessary work of enumerating the return payload and flagging when records will be absent. It stops short of describing empty-result behavior or format of the failure list, but that is a minor gap for a read-only statistics 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%, with date/days/group/material all documented inline, so the baseline is 3. The description only echoes the same concepts (某天/最近几天, 配置组) without adding format or matching semantics (e.g., what 模糊匹配 means for group) 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 opens with a specific read-only verb and resource ("战果统计（只读）") and then enumerates exactly what it reports: per-route pass/fail, durations, success/failure counts and failure lists, plus farming statistics and task_progress. It implicitly carves itself apart from bgi_run_one_dragon by noting that 一条龙 does not write execution records, though it never names a sibling tool 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?

The caveat "一条龙不写执行记录，只有配置组任务 / --startGroups / --TaskProgress 会写" tells the agent a precondition for meaningful results, which is genuinely useful routing information. However, it never says when to pick this over bgi_status or bgi_log_search, so the agent must infer the division of labor.

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

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

No annotations are present, but the definition covers the key behavioral trait: execution is asynchronous, the call returns immediately, and the outcome must be retrieved via bgi_watch. It does not say whether a failure in one group aborts the remaining groups in the sequence, or what preconditions (game instance/window) block a launch beyond the 'force' hint.

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

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

Two short sentences: the first states the action and its scope, the second states the async contract and the polling companion. Every clause earns its place, with the operational detail front-loaded.

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

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

For a tool with no annotations and no output schema, the description supplies the essential async contract and the sibling to poll, which an agent needs in order to call it correctly. The remaining gaps—failure semantics within a sequence and hard preconditions—are secondary and partly covered by the 'force' parameter description.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by tying the 'groups' string values to concrete files under User\ScriptGroup\, which tells the agent what kind of identifier to supply. The other three parameters (force, dry_run, wait_seconds) are left entirely to 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 definition names a specific verb and resource ('按顺序执行一个或多个「配置组」') and gives the concrete file path (User\ScriptGroup\<名>.json) that 'group' resolves to. It also separates the tool from siblings by saying that collection, hoeing, and custom-script orchestration all route here, and that status comes from bgi_watch, so an agent can tell it apart from bgi_run_js or bgi_collect_now without opening the schemas.

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 explains the correct usage pattern (fire-and-forget, then call bgi_watch to poll), which is the main decision an agent faces. It does not spell out when *not* to use this tool versus bgi_run_js or bgi_collect_now, and the prerequisite conditions are only hinted at through the 'force' parameter.

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

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

With no annotations, the description does disclose that this mutates state (creates a config group, downloads files, may trigger a run) and the schema's overwrite flag signals re-download. However it does not say what happens if a group with the same name already exists, whether the run is async, or what a failure looks like — significant gaps for a write-side tool with zero annotation coverage.

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

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

The arrow-delimited flow is front-loaded and scannable, and every clause conveys a step. The trailing sentence about JS being BetterGI's most powerful extension surface is mild marketing padding, but it does hint at use cases which marginally aids selection.

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 3-parameter mutation tool with no output schema and no annotations, the flow is described but return values, idempotency behavior, and error handling are unaddressed. Adequate to call correctly, not enough to predict outcomes.

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 are documented in the schema itself. The description reinforces run=true as the trigger condition but adds no format or edge-case detail (e.g., overwrite interaction with an existing group) 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?

Names a specific resource (official JS script) and spells out the three-step flow: ensure installed, generate a same-named config group, optionally trigger execution. It is distinguishable from bgi_install_js and bgi_create_group because it bundles both plus execution, 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?

The 'one-click run' framing and the run=true clause imply when to use it, but there is no explicit when-not, no pointer to bgi_install_js for install-only or bgi_run_groups for group execution. The agent must infer the boundary from the step list 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?

No annotations, so the description must carry the full behavioral burden. It does disclose the key non-obvious trait—fire-and-forget execution with a prerequisite that BetterGI must be closed—and routes to bgi_watch for outcomes, which is valuable. However, it does not describe what happens on partial completion, whether it can be interrupted, or what the returned value looks like, gaps that matter for a mutation/trigger tool with zero annotation coverage.

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

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

Two dense sentences: identity+pipeline first, then constraints and follow-up. No wasted text.

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

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

The description covers the trigger constraints and points at bgi_watch for results, which is what an agent needs for a no-output-schema async tool. Minor gaps remain around failure mid-run and partial completion handling.

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 each of the four params (force, config, dry_run, wait_seconds) is fully documented in the schema, so baseline 3 applies. The description mentions the default config name but adds no syntax or semantics 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 verb+resource ('跑「一条龙」日常配置') and enumerates the exact task pipeline it executes (领取邮件→合成树脂→领取每日奖励→自动秘境). It is clearly distinguishable from siblings that create or configure one-dragon setups.

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 states the precondition (BetterGI must not be running, since the single-instance behavior swallows args) and the post-call pattern (returns when done, poll success/failure with bgi_watch). Names the alternative sibling for result checking.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully states the prerequisite that BetterGI must not be running and that this resumes from the last interruption, but it does not describe side effects, what happens if the prerequisite is violated, or what the force behavior means beyond the schema.

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 statement with the core action and prerequisite front-loaded. Every clause adds useful information 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?

For a simple two-parameter action tool with complete schema coverage and no output schema, the description provides enough context to select and invoke it: purpose, interruption use case, and the key prerequisite. The main remaining gap is that it does not discuss return behavior or side effects, but that is less critical here.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description reinforces that the group name may be a specific group or latest, but adds no meaningful parameter semantics 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?

The description states a specific verb and resource: resume a configuration group from the last interruption. It also gives the exact CLI equivalent and clarifies the interrupted long-task context, which distinguishes it from normal run or collect siblings even without naming 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?

It clearly says to use this after a collection or long task has been interrupted, and it gives the prerequisite that BetterGI must not already be running. It does not explicitly name an alternative tool for starting a fresh run, so it falls short of full when/when-not/alternatives 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?

With no annotations, the description carries the full burden. It discloses that the operation is read-only ('只读') and lists the informational content returned, which is helpful. However, it does not describe side effects, permissions, error behavior, or output structure in detail beyond the content list.

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 that states the purpose and read-only nature before enumerating the returned data. It is dense but every clause contributes to describing the tool's scope, 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 no-parameter, read-only info tool with no output schema and no annotations, the description is fairly complete: it enumerates the categories of information returned. It does not explain how the data is structured or any caveats, but it covers enough for an agent to know what to expect.

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

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

The tool has zero parameters, so the baseline score is 4 per the rules. The description does not need to explain parameter semantics.

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

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

The description clearly states it provides a read-only schedule and run overview, and enumerates specific fields (trigger times, last/next run, return code, RunLevel, log tail, one-dragon config, etc.). It does not explicitly distinguish itself from siblings like bgi_status or bgi_results, but the scope is specific enough for an agent to understand what it 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 explicit guidance on when to use this tool versus alternatives such as bgi_status, bgi_results, or bgi_run_task_progress. The 'read-only' label implies a safe read operation, but no conditions, exclusions, or alternatives are mentioned.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the pre-call precondition, that an automatic backup occurs, and that a read-back verification follows the write. It does not say what happens on an invalid path, whether missing keys are created, or how errors surface, leaving a real gap.

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

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

Three short sentences, front-loaded with the action and target, followed by preconditions and side effects. Nothing is redundant with the name or schema, and every clause carries actionable information.

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

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

For a two-parameter mutation tool with no annotations and no output schema, it covers safety, preconditions, and side effects well. It leaves the caller without any notion of the response or error/failure behavior, which matters for a config-writing tool the user cannot run while the app is active.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds beyond it by expressing the path format as 父.子 (dot-separated parent.child) and reinforcing dry_run as a preview-only flag. It does not explain batching semantics or ordering of multiple entries in the changes array.

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 (安全修改/safely modify) and a concrete resource (User\config.json), plus the addressing syntax (父.子=值). That is far more specific than the name alone. It stops short of explicitly contrasting with siblings like bgi_js_settings or bgi_set_onedragon, which also write configuration, so differentiation is inferential.

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 states a hard prerequisite (BetterGI must be exited) and clarifies the preview mode (dry_run=true), which is exactly the context an agent needs before calling. No alternative tool or when-not-to-use case is named, so it falls short of the top mark.

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

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

With no annotations, the description carries the whole burden and does well: it discloses the required precondition (BetterGI stopped), that it auto-backs up, that it echoes before/after diffs, and that dry_run avoids the write. It omits error behavior for invalid field values (e.g. an illegal task name) and whether partial updates leave the rest of the JSON untouched.

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?

Front-loaded with what is changed and where, followed by the prerequisite, safety behavior, and preview flag — every clause earns its place. The single dense run-on paragraph is heavy for non-Chinese readers but not padded.

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 13-parameter mutation tool with no output schema and no annotations, the description supplies the precondition, backup/diff guarantees, and preview semantics that an agent needs to call it safely. It could still mention what a successful call returns or how to recover the backup, but the essentials are covered.

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 each of the 13 params is documented in-schema, so baseline 3 applies. The description's enumeration of fields (秘境/队伍/合成台地区/收工动作/保留原粹/按星期换秘境/任务顺序与启停) roughly mirrors the schema without adding format or interaction rules beyond it.

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

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

States a specific verb (改/modify) and resource (「一条龙」配置) and even names the target file path User\OneDragon\<名>.json, then enumerates the settings it touches (秘境/队伍/合成台地区/收工动作/按星期换秘境/任务顺序). It is distinguishable from create/add-group siblings by the explicit write-to-existing-config framing, though it never names those siblings to contrast with.

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

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

Gives a hard prerequisite (BetterGI must not be running, with the reason: it will write the file back and overwrite) and a preview path (dry_run=true 只预览). It does not say when to use bgi_create_onedragon or bgi_add_group_to_onedragon instead, so alternatives are left to inference.

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

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

With no annotations, the description carries the burden well: it discloses the 1-2 minute real startup time, the ~60s local MCP call ceiling, and that a 'still starting' return is not a failure. It omits idempotency behavior (effect if the game is already running) and process-side effects like spawning child processes.

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

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

Three sentences, front-loaded with purpose followed by the CLI equivalent and then the operational caveat. Every sentence carries information an agent needs to avoid misclassifying the timeout result.

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 annotations and no output schema, yet the description covers the timing profile, the timeout return shape, and the recovery path. What remains missing is the already-running case and the dry_run preview option, both of which an agent would want before calling.

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 dry_run and wait_seconds are already documented in the schema. The description's timeout discussion contextually relates to wait_seconds but never names or explains either parameter, so it adds no meaning beyond the schema. 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 action (launch Genshin + BetterGI screenshotter), anchored to a concrete CLI equivalent (BetterGI.exe start) and clarifies it chains into auto-login. An agent can distinguish this from bgi_close or bgi_status at a glance.

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?

Clearly implies use when the game is not running and explicitly routes the agent to bgi_status after a timeout return. It does not state exclusions (e.g. what to do if the game is already running) or prerequisites, so it falls short of a full when/when-not treatment.

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

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

No annotations exist, so the description must carry the safety profile — and it does, by declaring the tool read-only and bounding its output to specific sections including only the 'latest log tail' rather than full logs. It stops short of describing response shape or size limits, which is a modest gap for a low-risk read operation.

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

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

Two sentences, no filler: the first front-loads the enumerated scope, the second the mandatory usage rule. Each sentence earns its place.

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

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

For an aggregate status tool with no output schema, enumerating the six returned sections is the key completeness signal and it is present. Only the precise return format/layout is left unstated, which the JSON flag partially covers.

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

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

The single parameter is fully documented in the schema ('machine-readable JSON, default true'), so schema coverage is 100% and the description adds nothing param-specific. Baseline 3 applies since structured data does the work.

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 resource (BetterGI status) with explicit scope: process, window, key config, one-dragon config, latest log tail, progress file. This aggregate-overview framing distinguishes it from narrower siblings like bgi_schedule_info or bgi_run_task_progress. The 'read-only' qualifier further pins down what kind of tool it is.

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?

Explicit directive: 'call it first before any operation to confirm state' (任何操作前先调用它确认状态), which gives a clear trigger condition. No when-not conditions or named alternatives, but for a universal preflight tool that omission is minor.

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

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

With no annotations present, the description carries the full burden and does disclose the most important non-obvious trait: this is a blocking call capped near 50 seconds, and a timeout means call again rather than failure. It does not say what the response body looks like on match versus timeout, which is the remaining behavioral gap.

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 with a compact inline gloss list for the milestones, followed by a single practical note on the wait cap and retry. No filler, and the most important operational fact (50s cap, retry) lands last where it is easy to catch.

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, zero-required polling tool with no output schema, the description covers the milestone vocabulary, the blocking limit, and the retry loop — enough to invoke it correctly. What is missing is the return contract (does a timeout look like an empty result, an error, or the matched line?), which matters for an agent writing a retry loop.

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

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

Schema coverage is 100%, so the baseline would be 3; the description earns above that by glossing the non-obvious enum values (capturer_ready as screenshotter ready, domain_entered as actually entering the instance, finished as overall wrap-up). It also restates the 50-second cap consistent with the schema, though it says nothing about the pattern-overrides-milestone interaction 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?

States a specific verb (wait for) and resource (a milestone log line), and enumerates the exact milestone vocabulary, which lets the agent match it to a known workflow stage. The parenthetical 'really running, not just launched' clarifies intent versus plain status reads, but no sibling tool (bgi_status, bgi_watch, bgi_run_task_progress) is named.

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 context is implied — call this to confirm a run has actually started versus merely been dispatched — and the description gives a concrete retry pattern on timeout. However, it never states when to prefer bgi_watch, bgi_log_search, or bgi_run_task_progress instead, so the agent must infer the boundary itself.

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

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

With no annotations, the description carries the burden and does well: it declares read-only, repeatability, the 50s polling cap, and crucially that only current-run ERRs count as failures while earlier-run ERRs are listed separately. Missing only return-format details.

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?

Dense, front-loaded, and no filler; the read-only/repeatable nature and polling caveat are stated up front. Packed but 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?

No output schema exists, and the description compensates by explaining the verdict states and ERR scoping. Largely complete for an agent to call and interpret it, though return shape is only partially sketched.

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 parameters are already documented; the description reinforces wait_seconds' single-call polling semantics and the verdict=incomplete behavior. Baseline 3 is appropriate 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?

States a specific verb+resource: observe and judge success/failure of a run, plus read-only and repeatable nature. Distinguishes itself implicitly from siblings like bgi_status and bgi_results, though it doesn't 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?

Explains default immediate return, that verdict=incomplete means polling again later, and that wait_seconds polls up to 50s in a single call. Clear operational guidance, though no explicit 'use X instead' routing to siblings.

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