bizhawk_press

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately discloses the exact mapping (hold_frames=frames, release_frames=2), making the behavioral contract explicit: the button is held for 'frames' count and released over 2 frames. This is a precise behavioral specification for a mutation/input tool.

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 sentence that fully specifies the tool's behavior, including exact parameter mapping. This is maximally concise - no filler, every word carries meaning. It front-loads the identifier ('Legacy GB alias') and follows with the precise expansion.

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 simple 2-parameter alias with no output schema, this description is fairly complete. However, it's an input/control tool with no annotations, so it doesn't clarify whether this requires a running emulator, whether it works with any button string, or what the return value is. The effect on emulator state (press, hold for frames, release over 2 frames) is clear, but operational prerequisites are absent.

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. Both parameters are effectively documented: 'button' is the button to press, and 'frames' is mapped to hold_frames with the alias semantics explained. The description adds the default release_frames=2 value and the hold_frames=frames mapping, which goes beyond what the bare schema provides.

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?

Clearly identifies itself as a legacy alias for the tap operation, stating the exact equivalent call (`tap(button, hold_frames=frames, release_frames=2)`). The purpose is unambiguous - it's an alias for tapping with configurable hold frames. It doesn't explicitly differentiate from the emulator_ siblings, but its 'legacy GB' framing distinguishes it from the newer command family.

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 states it's a 'Legacy GB alias', which implies it should be used only for backward compatibility with the older GB command set, and that the newer `tap` equivalent exists. This gives partial guidance on when to use it versus alternatives, though it doesn't explicitly say 'use tap instead' or list exclusions.

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