Run multiple BetterGI config groups in sequence to orchestrate gathering, farming, or custom scripts. Returns immediately; poll with watch tool for status and results.
按顺序执行一个或多个「配置组」（User\ScriptGroup<名>.json）——采集/锄地/自定义脚本编排都走这里。立即返回；执行过程与成败用 bgi_watch 轮询。
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | 无视前置阻断强行发起（默认 false；窗口不可用时基本白跑） | |
| groups | Yes | 配置组名列表，按顺序执行 | |
| dry_run | No | 只打印命令不启动进程（默认 false） | |
| wait_seconds | No | 可选：等待截图器就绪的最长秒数（默认 0=立即返回，上限 50） |
Changes observed during successful MCP inspections.
v1.0.0Does 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.