01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100%, 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
27.6 / 30
03Economics
14.9 / 20
04Discoverability
8.6 / 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.
10 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
retroarch_state_slot_plus |
retroarch_state_slot_minus |
medium | Both mutate the current-slot pointer by one step in opposite directions; a vague instruction like 'change the save slot' or 'switch slots' gives no directional cue, so an agent could pick the wrong one. |
retroarch_save_state_current |
retroarch_load_state_current |
medium | Both operate on the currently-selected slot with symmetric semantics (save vs restore); a task phrased ambiguously like 'use the current save state' could be misread as either saving or loading. |
retroarch_load_state_current |
retroarch_load_state_slot |
high | Both load a savestate and share the 'load_state' name; a request like 'load slot 3' could tempt an agent to call load_state_current after walking the pointer, or a request like 'reload the current save' could be confused with naming a slot number, since the two tools differ only in whether the current-slot pointer is used or an explicit slot number is passed. |
retroarch_load_state_slot |
retroarch_state_slot_minus |
low | Share 'slot' terminology but do very different things (load vs pointer decrement); a poorly specified 'go back to previous slot state' request could momentarily conflate them, though the distinct verbs (load vs decrement) make confusion less likely. |
retroarch_load_state_slot |
retroarch_state_slot_plus |
low | Share 'slot' terminology but different actions (load vs pointer increment); a task like 'move to next slot and load it' could cause an agent to pick the wrong single tool if it doesn't realize two calls are needed. |
retroarch_read_memory |
retroarch_read_ram |
high | Both read emulated memory and return hex dumps; a generic request like 'read memory at address X' doesn't specify which address space (system memory map vs CHEEVOS), so an agent could pick either tool, especially since read_memory is only a fallback-preferred choice and the user may not know about the two APIs. |
retroarch_read_ram |
retroarch_write_ram |
low | Both use the CHEEVOS address space but perform opposite operations (read vs write); a task like 'check that value in RAM' is unlikely to be confused with writing, since the read/write verbs are unambiguous. |
retroarch_read_memory |
retroarch_write_memory |
low | Both use the libretro memory map but are opposite operations (read vs write); the explicit read/write verbs in a natural task make misselection unlikely despite shared address-space context. |
retroarch_write_memory |
retroarch_write_ram |
high | Both write byte sequences to emulated memory and are near-identical in purpose except for address space; a generic 'write this value into memory' request gives no signal about which API/address space to use, especially since write_memory is core-memory-map-dependent and write_ram is the fallback. |
retroarch_get_status |
retroarch_get_config |
low | Both are read-only 'get' tools on RetroArch, but one reports run-state/ROM identity and the other reads static config params; a vague 'get RetroArch info' request could momentarily blur them, though their described scopes (status vs config) are fairly distinct. |
Compare the field