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→98, token cost up 1%, 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
28.0 / 30
03Economics
18.1 / 20
04Discoverability
14.3 / 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 |
|---|---|---|
bb_clone |
no_return_description |
Clone a Bitbucket repository to your local filesystem using SSH (preferred, falling back to HTTPS if SSH keys are unavailable). Provide `repoSlug` and an absolute `targetPath`; the repo is cloned into `targetPath/repoSlug`. Optionally specify `workspaceSlug` (defaults to your configured or first available workspace). Returns the outcome of the clone operation, including the local path where the repository was cloned and the protocol (SSH or HTTPS) used, or an error message if the clone failed. |
Selection evidence
Confusable tool pairs.
11 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 |
high | Both update Bitbucket resources (e.g. repository metadata) with overlapping example endpoints like '/repositories/{workspace}/{repo}'; a task like 'update the repo description' doesn't clearly indicate full replace (PUT) vs partial update (PATCH), so an agent could easily pick either. |
bb_post |
bb_delete |
medium | Both operate on PR approval state (bb_post 'Approve PR' vs bb_delete 'Remove PR approval') using the same endpoint path with different HTTP verbs; a task like 'change my approval on this PR' could be ambiguous about which action is meant. |
bb_patch |
bb_delete |
low | Both act on PR comments (update vs delete) and repository resources, but the verbs 'update' vs 'delete' are usually distinguishable from task phrasing, making confusion less likely than the put/patch pair. |
bb_post |
bb_patch |
low | Both can target PR comments (create vs edit) and PRs generally; a vaguely worded task like 'add feedback to the PR' is normally clear about creating vs editing, so confusion is less likely but not impossible. |
bb_delete |
bb_clone |
low | Semantically unrelated (delete vs clone) but share only 'bb'/'bitbucket' tokens; unlikely to be confused given clone explicitly means local filesystem checkout. |
bb_get |
bb_clone |
low | A task like 'get the repository' could ambiguously suggest either fetching repo metadata (bb_get) or cloning it locally (bb_clone) if the user's intent (data vs local copy) isn't explicit. |
bb_get |
bb_delete |
low | Different HTTP verbs (read vs delete) are usually unambiguous in natural language tasks; minimal real confusion risk. |
bb_get |
bb_patch |
low | Read vs partial-update are distinct actions; unlikely to be confused except in vague 'check/update status' phrasing edge cases. |
bb_get |
bb_post |
low | Read vs create are distinct verbs generally clear from task phrasing; low ambiguity risk. |
bb_post |
bb_clone |
low | Creating a resource vs cloning a repo are conceptually distinct; unlikely to cause selection confusion. |
bb_put |
bb_clone |
low | Replacing a resource vs cloning locally are distinct operations with little overlap in typical task phrasing. |
Compare the field