execute_scenario

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

With no annotations, the description carries the behavioral disclosure burden. It does well by detailing what executing a scenario produces: step-by-step logs, screenshots after each state-changing step, API errors observed, and final page state. It does not mention potential side effects on the application under test, but the disclosed execution details are substantive.

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 tight sentences: the first front-loads the core action and outputs; the second adds provenance guidance. No filler, repetition, or unnecessary detail.

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?

The schema richly covers the nested scenario and step fields, and the description covers return behavior since there is no output schema. It is generally complete for calling the tool, though it would be stronger with explicit guidance on when to choose this versus run_full_test and a note about side effects.

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 the baseline is 3. The description itself adds little parameter-level semantics beyond noting that scenarios may be constructed from scan_codebase output, but the schema already documents scenario, authenticated, and all nested step fields thoroughly.

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 clearly names the verb ('execute'), the resource ('a single test scenario'), and enumerates the step types (navigate/fill/click/assert) and result contents (logs, screenshots, API errors, final page state). The word 'single' helps distinguish it from sibling run_full_test, which suggests a broader full-suite execution.

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 gives useful context that scenarios can be built from scan_codebase output or created custom, which implies a valid usage pathway. However, it does not explicitly state when to prefer this tool over alternatives like run_full_test or run_converge, nor does it provide exclusions.

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