renforge_launch

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

With no annotations, the description carries full burden, and it delivers: it discloses the async behavior (waits 20s then returns status='starting'), the need to poll for 'ready'/'failed', editor default and override, savedir isolation, and timeout semantics. It does not contradict any annotations.

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

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

The description is front-loaded with the purpose, then moves to parameter instructions and the workflow. It is dense but every sentence adds relevant information, with minimal redundancy and a useful docs pointer.

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 10-parameter launch tool with async startup, the description covers the main workflow, defaults, and error/polling states well. It is incomplete on a few parameters (version, persistent, cleanup_on_stop) and relies on docs/LIVE_EDITOR.md for further detail, but the output schema reduces the need to document return values.

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 0%, so the description must compensate, and it explains the meaning of editor, warp, display/audio defaults, savedir, and timeout. However, it leaves version, persistent, and cleanup_on_stop unexplained, and project_path is only implicit.

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 'Launch or reuse a game with the Live Editor enabled by default,' giving a specific verb and resource. It is clear about the core action, though it doesn't explicitly contrast itself with sibling tools like renforge_new_game or renforge_launch_status.

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

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

It provides a concrete post-launch workflow: poll renforge_launch_status until ready, observe with renforge_screenshot/renforge_scene_tree, use frame_id-guarded clicks, and stop with renforge_stop. This is clear context, but there are no explicit when-not-to-use or alternative-tool exclusions.

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