Public assessment

aashari/mcp-server-atlassian-jira (@aashari/mcp-server-atlassian-jira)

aashari-mcp-server-atlassian-jira · v3.3.0 · scanned Aug 3, 2026

What changed in the harness

Selection accuracy 89%, 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.

01Safety

0.0 / 30

0.0 out of 30

02Legibility

27.0 / 30

27.0 out of 30

03Economics

18.5 / 20

18.5 out of 20

04Discoverability

14.0 / 20

14.0 out of 20

Highest-impact fix

Estimated gain +30 points

Add 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.

3 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`jira_put`	`jira_patch`	high	Both tools perform 'update' operations with near-identical schemas (path+body), and each description references the other (PUT says 'for partial updates prefer PATCH'; PATCH says 'only updates fields you specify'). Natural tasks like 'update the issue summary' or 'change the assignee' give an agent no lexical cue to distinguish full-replace PUT from partial PATCH, so either member is a plausible wrong pick.
`jira_post`	`jira_put`	medium	Both take a body and path and are listed under mutation operations, so tasks phrased as 'upsert', 'ensure this issue matches', 'create or update the project details', or 'set the project fields' are ambiguous between creating (POST) and fully replacing (PUT); an agent acting on the shared 'resource' intent can pick the wrong HTTP verb.
`jira_post`	`jira_patch`	medium	Wording overlap between creating and editing: POST handles 'transition issue' and 'add comment/worklog', while PATCH handles 'update comment/worklog' and status fields. A task like 'move this issue to In Progress' or 'modify the comment text' could be routed to either POST (via /transitions, /issue/{id}/comment) or PATCH (via issue field/comment update) since both accept a body on overlapping paths.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard