01Safety
0.0 / 30
Public leaderboard
Public assessment
aashari/mcp-server-atlassian-jira (@aashari/mcp-server-atlassian-jira)
What changed in the harness
Selection accuracy 98→93, token cost down 30%, 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
25.3 / 30
03Economics
18.3 / 20
04Discoverability
15.7 / 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.
5 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 |
|---|---|---|
jira_get |
params_unexplained no_return_description |
Executes a GET request against any Jira Cloud REST API v3 endpoint (projects, issues, search, comments, worklogs, transitions, users, statuses, etc.) using the given path and optional queryParams, returning the parsed API response filtered by the optional jq (JMESPath) expression and formatted as TOON by default or JSON when outputFormat is set to "json". |
jira_post |
params_unexplained no_return_description |
Executes a POST request against a Jira Cloud REST API v3 endpoint to create resources (issues, comments, worklogs, transitions, etc.) using the given path and required JSON body, with optional queryParams, returning the created resource's data filtered by the optional jq (JMESPath) expression and formatted as TOON by default or JSON when outputFormat is set to "json". |
jira_put |
params_unexplained no_return_description |
Executes a PUT request against a Jira Cloud REST API v3 endpoint to fully replace a resource (e.g. an issue or project) using the given path and required JSON body, with optional queryParams, returning the API response filtered by the optional jq (JMESPath) expression and formatted as TOON by default or JSON when outputFormat is set to "json". |
jira_patch |
params_unexplained no_return_description |
Executes a PATCH request against a Jira Cloud REST API v3 endpoint to partially update a resource (e.g. specific issue fields, a comment, or a worklog) using the given path and required JSON body containing only the fields to change, with optional queryParams, returning the API response filtered by the optional jq (JMESPath) expression and formatted as TOON by default or JSON when outputFormat is set to "json". |
jira_delete |
params_unexplained no_return_description |
Executes a DELETE request against a Jira Cloud REST API v3 endpoint to remove a resource (issue, comment, worklog, attachment, or watcher) using the given path and optional queryParams, returning the API response (typically empty on 204 No Content) filtered by the optional jq (JMESPath) expression and formatted as TOON by default or JSON when outputFormat is set to "json". |
Selection evidence
Confusable tool pairs.
10 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 update an existing Jira issue via body.fields with overlapping example payloads (e.g. updating summary); an agent asked to 'update an issue field' could easily pick PUT (full replace) when PATCH (partial) is correct, or vice versa, since the distinction (full vs partial update) is subtle and only stated in prose, not enforced by schema. |
jira_post |
jira_delete |
low | POST creates and DELETE removes — opposite operations with clearly distinct verbs in their descriptions, so confusion is unlikely except for oddly-phrased tasks like 'remove a watcher' vs 'add a watcher', which don't overlap in a way that would cause tool misselection. |
jira_patch |
jira_delete |
low | PATCH modifies fields (e.g. clearing a value to empty) versus DELETE removing a whole resource (e.g. comment/worklog); a task like 'remove the comment text' could ambiguously suggest either patching the comment to blank or deleting it, but this is a narrow edge case. |
jira_post |
jira_patch |
medium | Both can act on sub-resources like comments/worklogs (POST creates a comment, PATCH updates an existing one); a vague instruction like 'add a note to the worklog' could be misread as creating vs modifying, causing selection ambiguity. |
jira_get |
jira_delete |
low | Read vs delete are clearly opposed operations; no plausible natural-language task would blur retrieving data with removing it. |
jira_get |
jira_patch |
low | GET only reads while PATCH mutates state; despite sharing the same path patterns, the read/write distinction is unambiguous from typical task phrasing. |
jira_get |
jira_post |
low | GET is read-only and POST creates; both share the same endpoint style but the create-vs-read intent in a task description makes tool choice clear. |
jira_get |
jira_put |
low | GET reads, PUT replaces a resource; unlikely to be confused since fetching data and overwriting a full resource are distinct actions typically stated explicitly. |
jira_post |
jira_put |
medium | Both take a body and path with overlapping examples on '/rest/api/3/issue/{issueIdOrKey}'-style endpoints; a task like 'set the issue fields' doesn't clearly indicate create-new vs full-replace-existing, especially since POST's issue creation and PUT's issue field replacement share very similar body shapes. |
jira_put |
jira_delete |
low | PUT replaces a resource's content while DELETE removes it entirely; these are semantically distinct enough that natural-language tasks rarely confuse them. |
Compare the field