bg3_game_restart

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 well: it discloses that the game is killed, that unsaved progress is lost, the exact relaunch mechanisms (Steam -applaunch vs game exe for GOG), that --skip-launcher -continueGame loads the NEWEST save, and that it blocks until a host character is loaded.

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

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

A single dense sentence, front-loaded with the kill/deploy/relaunch sequence. The parenthetical clauses (deploy fallback, Steam vs GOG, launcher flags) all earn their place, though the nested parentheses reduce immediate readability slightly.

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

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

For a destructive, side-effect-heavy tool with an output schema present, the description covers the important behavioral facts (data loss, blocking wait, launch variants). It is complete enough to call correctly; only the absence of explicit when-to-use guidance keeps it from a 5.

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

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

Schema description coverage is 0%, but the description supplies real meaning for both parameters: 'launch' maps to the relaunch step and 'deploy_layer' to the optional mod layer selection. It stops short of stating parameter names or the null/default semantics, so it only partially compensates for the schema gap.

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 sequence (kill, deploy, relaunch, wait) on a specific resource (the BG3 game process), and explicitly routes the mod-layer step to either a layers.json deploy command or the built-in bg3_deploy sibling. An agent can distinguish it from bg3_deploy or bg3_refresh without opening any 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 says what happens on each step and that deployment is optional, and it names the alternative deploy mechanism. However, it never states when an agent should call this full restart vs just bg3_deploy or bg3_add_mod_layer, so the usage decision 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.