Loading ToolBench
A powerful Model Context Protocol (MCP) server for Atlassian JIRA integration. Access JIRA projects, manage issues, and streamline development workflows directly from any MCP-compatible editor or application.
14 tools with mostly present but inconsistent schema and description quality. Tool naming follows verb_noun conventions well (get_, create_, update_, delete_, search_, add_). Descriptions are present and reasonably clear (averaging ~120-180 chars), meeting baseline length. However, input schemas show critical gaps: parameter descriptions are minimal or absent in several tools, and optional parameter handling is unclear. Output schemas are not documented anywhere in the provided code. Error handling exists at the base class level but lacks actionable recovery guidance per-tool. No tool annotations (readOnlyHint/destructiveHint) are visible, despite clear WRITE/DESTRUCTIVE risk classifications. The server uses Zod for validation internally but does not expose rich constraint information to the LLM. Pagination support exists for some read tools (maxResults, startAt in search_jira_issues) but is inconsistently applied.
Add a worklog entry to track time spent on an issue
Creates a new JIRA issue with specified parameters
Delete a worklog entry from an issue
Retrieves all JIRA issues assigned to the current user
Get all accessible JIRA boards with filtering by type, project, and name
Get current user profile information and permissions
No output schemas documented. Tools return results but LLMs cannot see what fields to expect. For example, jira_get_issue returns a full issue object, but the description does not specify which fields are included, their types, or what downstream tools expect.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. jira_delete_worklog is marked DESTRUCTIVE in metadata but carries no annotation in the MCP tool definition, so the LLM cannot see that it is irreversible without reading the description carefully.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Retrieves detailed information about a specific JIRA issue
Retrieves comments for a specific JIRA issue with configurable quantity and filtering options
Get all accessible JIRA projects with filtering and search capabilities
Get all sprints for a specific JIRA board with filtering by state
Get all worklog entries for a specific issue
Updates an existing JIRA issue with field changes, status transitions, and worklog entries
Update an existing worklog entry
Search JIRA issues using JQL queries or helper parameters. Supports both expert JQL and beginner-friendly filters.
Parameter descriptions are minimal or generic. For example, jira_update_issue takes a 'fields' parameter of type 'object' with description 'Fields to update', but does not explain what fields are valid, which are required, or provide examples. This forces LLMs to guess or make extra discovery calls.
Pagination inconsistently applied. search_jira_issues accepts maxResults and startAt; jira_get_issue_comments accepts maxResults and expand; but many read tools (jira_get_projects, jira_get_boards, jira_get_sprints) lack pagination parameters entirely. If these APIs return lists, unbounded results risk context exhaustion.
No error recovery guidance in tool descriptions. BaseToolHandler catches errors and returns a formatted error response, but each tool description does not explain what errors are possible, why they happen, or what the LLM should do next. For example, jira_get_issue could fail if the issue key is invalid, but the description does not suggest trying search_jira_issues first.
jira_update_issue 'transition' parameter lacks specificity. Parameter is typed 'object' with description 'Status transition details', but does not explain what fields are required (e.g., 'id', 'name'), what valid transition names are, or how to discover available transitions.
No confirmation or dry-run pattern for destructive operations. jira_delete_worklog permanently deletes time entries with no undo or confirmation step. Agents can invoke this without explicit user approval, risking data loss.