01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→100, token cost up 2%, unconfirmed writes 0%→0%.
Category breakdown
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
0.0 / 30
29.0 / 30
19.4 / 20
11.9 / 20
Highest-impact fix
Estimated gain +30 pointsExpose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
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 |
|---|---|---|
update_status |
name_restates_behavior |
Update a change request's status as it moves through the build and review flow. Pass the ticket code for the request and the new status (new, accepted, building, preview, approved, shipped, or rejected). Useful after you begin working on a request, set up a preview, or ship it, so the requester and other tooling track where the request is. Returns the code and the newly set status. |
Selection evidence
2 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
list_change_requests |
get_change_request |
medium | A task like 'get me the change requests users submitted' or 'show me that change request' can ambiguously mean listing all requests or fetching a single request's detail, especially when no ticket id is provided yet; |
set_preview_url |
publish_preview |
high | Both descriptions literally say 'mark it ready for the requester to review,' so a task like 'mark RB-3 ready for review' or 'activate the preview for this request' gives no hint whether a new deploy-preview URL must be attached or an already-live preview should be published, |
Compare the field