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
29.0 / 30
03Economics
18.4 / 20
04Discoverability
15.4 / 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.
9 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
prior_search |
prior_contribute |
low | Both relate to sharing/finding solutions but have clearly distinct verbs (search vs share) and different required params (query vs title/content), so confusion is unlikely. |
prior_search |
prior_feedback |
low | A task like 'let Prior know this search result worked' could momentarily be confused with re-searching, but the outcome/entryId requirement in feedback makes intent clear once schema is read. |
prior_feedback |
prior_retract |
low | Both act on an existing entryId, but 'remove this bad result' could plausibly be phrased ambiguously between marking feedback as not_useful/irrelevant versus retracting the entry entirely, especially if the agent conflates 'this is wrong' with 'delete this'. |
prior_contribute |
prior_retract |
low | Opposite operations (add vs remove) with distinct required fields, unlikely to be confused by a natural-language task. |
prior_contribute |
prior_status |
low | No functional overlap; status just reports credits/tier while contribute submits content, low ambiguity. |
prior_feedback |
prior_status |
low | Distinct purposes (rating a result vs checking account status), minimal risk of selection confusion. |
prior_search |
prior_retract |
low | No semantic overlap between searching and retracting an owned entry. |
prior_search |
prior_status |
low | No semantic overlap between searching solutions and checking agent account status. |
prior_status |
prior_retract |
low | Distinct purposes with no shared verbs or parameters beyond the 'prior' prefix. |
Compare the field