01Safety
0.0 / 30
What changed in the harness
Selection accuracy 98%, 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
28.5 / 30
03Economics
10.1 / 20
04Discoverability
13.8 / 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.
4 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
create_qurl |
batch_create_qurls |
medium | Tasks like 'make access links for each of these 10 recipients' leave cardinality implicit; an agent must decide between looping create_qurl and batch_create_qurls, and both definitions present themselves as the 'create qURL' entry point with nearly identical schemas. |
list_qurls |
list_qurl_sessions |
medium | A task such as 'show me the active sessions/activity on my qURLs' pairs naturally with both names: list_qurls returns active-status resources while list_qurl_sessions returns live access sessions, and the sessions-vs-resources distinction is a subtle domain nuance not obvious from the shared 'list qurl' prefix. |
update_qurl |
update_qurl_token |
medium | Both accept expiration and label-ish edits; only the resource-level vs token-level scope and the r_/q_ ID requirements differ. A task like 'tighten the policy on link q_abc or limit its sessions' can route to update_qurl because the names match, even though only update_qurl_token exposes access_policy, max_sessions, and session_duration. |
revoke_qurl_token |
update_qurl_token |
medium | Wording like 'make this token stop working' or 'deactivate/expire this access token' is ambiguous: revoke_qurl_token kills it outright while update_qurl_token can force an immediate expiry, and both tools share the same required inputs (r_ resource_id + q_ token), so the choice hinges on intent nuance rather than schema. |
Compare the field