Downloads or verifies an official BetterGI JavaScript script, generates a matching single-script configuration group, and optionally triggers execution for automation tasks like daily commissions or resin.
一键跑官方 JS 脚本：确保已安装 → 生成同名配置组（单个 Javascript 项目）→（run=true 时）触发执行。JS 脚本是 BetterGI 能力最强的扩展面（自动委托、树脂、纪行、尘歌壶、抽卡兑换等）。
| Name | Required | Description | Default |
|---|---|---|---|
| run | No | 建组后立即触发（默认 false） | |
| name | Yes | 仓库 js/ 下的目录名 | |
| overwrite | No | 重新下载脚本文件（默认 false） |
Changes observed during successful MCP inspections.
v1.0.0Does 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.