launch_start

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

Annotations provide openWorldHint=true and destructiveHint=false, but the description adds significant behavioral context beyond that: it opens a new browser window, enables debug logging, explains the adopted flag semantics (attaches to existing runtime only when no options passed), describes the ready flag meaning, and notes popup-blocking as a failure mode. The only mild gap is not detailing side effects on a previously running runtime instance, but the adopted explanation covers the main behavioral nuance.

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 well-organized: it front-loads the core action and effect, then the return contract, then the prerequisite/retry guidance, and finally the exclusion list. Every sentence earns its place. It is longer than average, but the tool has nontrivial semantics (ready/adopted flags, popup blocking, fresh-launch behavior) that justify the length. Slightly trimmed phrasing on the adopted clause would make it a 5.

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?

Given the tool's complexity — return flags needing interpretation, a browser-window side effect, failure modes, and prerequisite relationships to many sibling tools — the description covers everything an agent needs to invoke it correctly and interpret its result. The output contract ({ url, sceneId, ready, adopted }) is fully explained, which matters because there is no output schema. The failure handling for ready=false is explicitly specified. 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 description coverage is only 25%, so the description compensates somewhat by explaining that passing any option forces a fresh launch rather than adoption — this adds meaning to the parameter set as a whole. However, the description does not explain individual parameters like debug, bundles, profiler, miniStats, concatenate, or engineVersion, which remain undocumented in both the schema and description. The device enum has a schema description, and waitMs has one, but the remaining booleans are opaque. The baseline is 3 and the description adds aggregate-level semantics, but per-parameter meaning is still missing.

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: 'Start a real Launch runtime instance of the current scene...' It is immediately distinguishable from siblings like capture_viewport (editor screenshot), capture_runtime (uses the launched runtime), and launch_stop (the inverse operation). The phrase 'the editor's Launch button' grounds it in a familiar concept, and the explicit 'When NOT to use' list further differentiates it from capture_viewport and edit-time tools.

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 description explicitly states when to use ('This is the prerequisite for all runtime tools'), what to do if ready=false ('poll read_runtime_logs or retry'), and when NOT to use, naming the alternative tools (capture_viewport for screenshots, edit-time tools for scene changes). It also explains the adoption edge case and how to force a fresh launch by passing an option. This is comprehensive routing guidance.

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