01Safety
0.0 / 30
What changed in the harness
Selection accuracy 92→84, token cost down 0%, unconfirmed writes 0%→0%.
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.7 / 30
03Economics
19.0 / 20
04Discoverability
10.0 / 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.
1 defect 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 |
|---|---|---|
track_interaction |
no_return_description |
Track a user interaction with a torrent (magnet link click, .torrent download, or hash copy). Use this after presenting a magnet link or torrent URL to the user, to keep popularity stats accurate. Fire-and-forget — does not block; returns immediately with a lightweight confirmation object but provides no detailed result. |
Selection evidence
Confusable tool pairs.
2 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
get_popular |
get_recent |
medium | Both return paginated lists of movies/TV shows with the same schema, differing only in sort order (click count vs. addition date). A user saying 'what's hot right now' or 'what should I watch' could plausibly map to either, and a request like 'what's new and trending' is genuinely ambiguous without clarifying which ordering is meant. |
submit_scan_request |
get_scan_status |
medium | Both target the same audio/video torrent-scan domain and take an info_hash. A task like 'check the quality specs of this torrent' could cause the agent to call get_scan_status (when no scan was ever submitted) or submit_scan_request (when the user only wanted to check an existing scan's progress), since neither description fully disambiguates 'kick off a scan' vs. 'retrieve scan status' without explicit wording. |
Compare the field