emulator_run_scenario

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

No annotations are provided, so the description carries full behavioral disclosure burden, but it reveals nothing about what happens during execution - whether it blocks, mutates emulator state, requires the emulator running, or affects ongoing sessions. It does not describe results, side effects, or failure modes. For a stateful run-on-target tool, this is a substantial gap.

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 a single efficient sentence with no filler or redundancy. It's appropriately short, though the brevity comes at the cost of substance rather than being a model of tight informative writing.

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 a mutation-style run tool with two parameters at 0% schema coverage, no output schema, and no annotations, the description provides only bare-minimum framing. It does not explain return values, valid target values, scenario file format, or relationship to sibling emulator scenario tools. Not enough for an agent to confidently invoke this tool.

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%, so the description must compensate, but it adds no parameter information beyond the schema. It doesn't explain what 'path' should point to (file vs directory, supported format), nor what 'target' means or what valid values are (the default 'gb' hints at Game Boy but is unexplained). The two parameters are effectively undocumented by the description.

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 'Run a JSON scenario file against a target' names a verb and resource, but terminology is vague - 'target' could refer to emulator, device, or platform, and 'scenario' is undefined. There is a sibling `emulator_run_pair_scenario` and `bizhawk_run_scenario`, yet no distinguishing details clarify how this differs from running a scenario against a pair or the bizhawk variant. The purpose is only minimally clear.

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?

No guidance on when to use this tool versus `emulator_run_pair_scenario` or related scenario tools. Context is implicit (the tool name suggests it runs scenarios), but there are no explicit exclusions or alternative tool references, and the description doesn't clarify prerequisites like whether the emulator must be started or a scenario file format required.

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