Loading ToolBench
Model Context Protocol server for Atlassian Jira integration - search issues, get details, and access comments from your Jira workspace
jira-mcp provides 11 tools with explicit schemas and descriptions visible in src/index.ts. Tool naming follows verb_noun conventions (jira_get_*, jira_create_*, jira_update_*, jira_search_*, jira_add_*, jira_delete_*, jira_link_*) and is action-oriented. Descriptions are present and moderately detailed (avg ~80-150 chars), exceeding the critical minimum. Input schemas are properly defined with types, required fields, and parameter descriptions. However, output schemas are NOT documented, the code lacks response type definitions or examples showing what fields agents should expect. Error handling is minimal; no guidance on recovery, retryability, or actionable corrections. Parameter constraints are documented in descriptions (e.g., 'YYYY-MM-DD format') but lack formal enum definitions where applicable (e.g., priority values, issue types). Several tools accept free-form string parameters that would benefit from enums or validation hints. Per-tool analysis shows consistent quality across the board: all 11 tools have descriptions and schemas, but none document their responses or error paths.
Add a comment to a Jira issue
Create a new Jira issue
Delete an issue link by its ID. Use jira_get_issue_links to find the link ID first.
Get all available fields in Jira including custom fields
Get a specific Jira issue by key (e.g., PROJECT-123)
Get comments for a specific Jira issue
Output schemas are completely undocumented. No tool includes a response schema, field descriptions, or examples of return values. LLMs cannot plan downstream actions without knowing what fields to expect (e.g., does jira_get_issue return assignee_id or assignee_email? both? neither?).
Error handling is absent. No guidance on what constitutes a recoverable vs. fatal error, what the agent should do on 404 (try search first?), or how to correct invalid inputs. Agents cannot self-recover.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get all issue links for a Jira issue. Returns link IDs, types, and linked issues.
Get available status transitions for a Jira issue
Create a link between two Jira issues. Direction: the inward issue performs the action on the outward issue — for 'Blocks', inwardIssueKey BLOCKS outwardIssueKey. To make A block B, pass inwardIssueKey=A, outwardIssueKey=B. The result message reports the direction Jira actually stored.
Search for Jira issues using JQL
Update a Jira issue (change status, assignee, etc.)
Free-form string parameters lack enum constraints where semantically justified. 'priority' accepts 'High, Medium, Low' per description, but no enum definition. 'issueType' defaults to 'Task' with examples 'Bug, Story, Task' but no enum. 'linkType' lists examples 'Blocks, Relates to, Duplicates' without enum. LLMs may hallucinate invalid values.
No pagination support or result limits documented. jira_search_issues accepts 'maxResults' with default 50, but no mention of what happens if a JQL query matches 10,000 issues or if responses are paginated with offset/cursor. Agents may request huge result sets or miss pagination entirely.
Destructive operations (jira_delete_link) lack confirmation or dry-run support. No warning that deletion is irreversible. No undo/compensation tool if a link is deleted by mistake.
Configuration via environment variables (JIRA_BASE_URL, JIRA_EMAIL, JIRA_API_TOKEN) is hardcoded in index.ts with defaults like 'https://your-domain.atlassian.net'. No validation that these are set before startup; a missing API token will silently fail at runtime with unhelpful API errors.
Parameter relationships are underdocumented. jira_update_issue has many optional fields (transition, assignee, summary, priority, etc.) with no guidance on whether some are mutually exclusive or dependent. Agents may make invalid combinations.