01Safety
0.0 / 30
What changed in the harness
Selection accuracy 93%, destructive-action safety rate 0% (baseline only -- no rewrite pass applied).
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
26.9 / 30
03Economics
13.8 / 20
04Discoverability
7.7 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
0 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
| No description defects were flagged in this assessment. | ||
Selection evidence
Confusable tool pairs.
8 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
dolphin_press_gc_buttons |
dolphin_press_wiimote_buttons |
high | A task like 'press A to confirm' or 'press right to move in the menu' never states the controller type, and both tools accept the same button names (A, B, d-pad). The GC tool's note that 'Wii games sometimes accept GC controllers — try port 0 if unsure' actively invites a wrong pick, and the mistaken input silently does nothing. |
dolphin_set_wiimote_acceleration |
dolphin_set_wiimote_angular_velocity |
medium | Identical signatures (port plus x/y/z floats) and identical ClearOn::NextFrame semantics. Motion phrasing like 'tilt the remote', 'rotate the controller', or 'spin to attack' maps plausibly to either a linear accelerometer reading or an angular-velocity reading; nothing in the task says which sensor the game reads. |
dolphin_press_wiimote_buttons |
dolphin_set_wiimote_pointer |
medium | A task like 'select the menu option' or 'click Play' can be fulfilled either with D-pad button presses or with the IR pointer, and the pointer tool's own description bills itself for 'menu navigation'. The agent may pick the input method the game actually ignores. |
dolphin_read16 |
dolphin_read32 |
medium | Tasks like 'read the player's HP/score at 0x8000A000' rarely state the field width, and the guidance conflicts: read16 lists HP/score/coordinates as its targets while read32 is declared 'the workhorse — most game state ... is 32-bit'. The wrong width yields a corrupted value. |
dolphin_write16 |
dolphin_write32 |
medium | Mirrors the read ambiguity: 'set the score/HP to N at address X' doesn't fix the width, and the tool descriptions overlap the same game-state examples (16-bit HP/score vs 32-bit workhorse). The wrong pick writes across the wrong byte span. |
dolphin_read8 |
dolphin_read32 |
low | A vague 'read the value at 0x...' task offers no width cue: read8 is billed for flags/counters/small enums while read32 is the default workhorse, so an agent can plausibly mis-size a field (picking the workhorse for a byte field, or read8 when the game stores the field as 32-bit). |
dolphin_read32 |
dolphin_read64 |
low | For possibly-64-bit fields (doubles, packed pairs) read32's 'workhorse, most game state is 32-bit' framing can win out over the rarer read64 and truncate the read; conversely 'read the large number' may pull an agent to read64 for an ordinary 32-bit field. The read64 description even warns against this misuse. |
dolphin_read_range |
dolphin_screenshot |
low | A task phrased as 'check the game's current state' is ambiguous between capturing what's on screen (screenshot: 'confirm game state, read a menu/HUD') and dumping RAM (read_range: 'region capture, snapshot-diff RAM hunting'), since both descriptions claim state inspection. |
Compare the field