01Safety
0.0 / 30
Public leaderboard
Public assessment
aashari/mcp-server-atlassian-bitbucket (@aashari/mcp-server-atlassian-bitbucket)
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.1 / 30
03Economics
18.3 / 20
04Discoverability
15.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.
5 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
bb_put |
bb_patch |
medium | Both are update tools with overlapping endpoints: 'update repository' (description/is_private) appears under bb_put and 'update repository properties' under bb_patch, so a task like 'change the repo description' is ambiguous between full replace and partial update. |
bb_post |
bb_patch |
medium | An 'add a reviewer to this PR' task can trigger bb_post (create semantics) even though updating reviewers is a bb_patch operation; create vs. partial-update distinction is unclear from natural wording. |
bb_get |
bb_clone |
low | A task like 'get the repository' or 'download the repo' is ambiguous between fetching repo data (bb_get) and cloning to the local filesystem (bb_clone), since both share 'bitbucket/repository' vocabulary. |
bb_post |
bb_delete |
low | Review-outcome tasks are ambiguous: 'reject this PR' could map to request-changes (bb_post) or decline (bb_delete), and 'unapprove' sits between approve (bb_post) and remove approval (bb_delete). |
bb_patch |
bb_delete |
low | A task like 'remove a reviewer from the PR' can suggest bb_delete (delete/remove semantics) when the correct tool is bb_patch updating the reviewers array, since bb_delete lists no reviewer endpoint but 'remove' reads as destructive. |
Compare the field