Loading ToolBench
Model Context Protocol (MCP) server for Jira integration with Claude Code and AI assistants. Provides tools to interact with Jira API: create and manage issues, sprints, boards, projects and workflows.
The Jira MCP server has solid foundational structure with 9 well-named tools covering core Jira operations. Naming follows verb_noun conventions consistently (create_issue, get_issue, list_issues, etc.). All tools have descriptions and structured input schemas. However, there are notable gaps: parameter descriptions lack detail about constraints (e.g., priority values, project_key format), output schemas are not documented, error handling is minimal, and some parameters accept opaque IDs without accepting human-friendly identifiers (e.g., assignee_id requires account ID rather than name/email). The descriptions are functional but generic, averaging ~60-80 characters, below the 50-200 char optimum for LLM intent matching. No tool annotations (readOnlyHint, destructiveHint) are visible despite tools having clear risk levels (DESTRUCTIVE, WRITE, READ_ONLY). The additional_fields parameter is underspecified, accepting a bare 'record' type without guidance on valid fields or format.
Add a comment to a Jira issue
Create a new Jira issue (Story, Bug, Task, Epic, etc.)
Delete a Jira issue by key or ID
Get detailed information about a specific Jira issue
Get all fields (including custom fields) for an issue with their names and values
Get available status transitions for an issue
Search for issues using JQL (Jira Query Language)
No output schemas documented. LLMs cannot determine what fields to expect from tool responses, forcing them to guess at response structure and breaking downstream tool chaining.
Opaque ID parameters without human-readable alternatives. assignee_id requires Jira account ID rather than accepting email, username, or display name. Forces agents to perform unnecessary lookups before calling create_issue or update_issue.
Parameter constraints not specified in descriptions. 'priority' accepts string but valid values (High, Medium, Low, etc.) not enumerated. 'issue_type' similarly lacks enum values. LLMs will hallucinate invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Transition an issue to a new status
Update an existing Jira issue (summary, description, assignee, priority, labels, custom fields)
No tool annotations visible. delete_issue is DESTRUCTIVE but no destructiveHint annotation found. get_issue is READ_ONLY but no readOnlyHint found. Agents cannot distinguish safe from dangerous operations without annotations.
generic parameter descriptions. 'additional_fields' defined as 'record' type with description 'Additional fields as key-value pairs (e.g., custom fields)' provides no guidance on valid field names, types, or format. LLMs will guess and fail.
No error handling guidance visible. If create_issue fails due to invalid project_key or issue_type, no actionable recovery suggestion provided to the LLM (e.g., 'Call list_projects() to find valid keys').
No dry-run or confirmation mechanism for destructive operations. delete_issue permanently removes issues with no undo prompt. Agents make mistakes, a confirmation pattern would prevent catastrophic data loss.
list_issues returns 'next_page_token' for pagination but default max_results=20 may be arbitrary. No documentation of actual response structure (total count, items array, etc.) or guidance on when to paginate.
Parameter descriptions too short (10-60 chars in most cases, vs 50-200 char optimum for LLM clarity). Descriptions like 'Issue description (plain text)' and 'Issue key (e.g., PROJ-123) or ID' provide minimal context for LLM intent matching.