Loading ToolBench
A Model Context Protocol server for Jira issue management and operations
Jira Basic MCP has 11 well-defined tools with complete input schemas and consistent naming conventions. Tool names follow verb_noun pattern (delete_issue, get_issues, create_issue, etc.) which is excellent for LLM parsing. All tools have descriptions and complete JSON schemas with type definitions. However, several critical gaps reduce the score: (1) Output schemas are not documented, responses are sanitized internally but the tool definitions don't specify what fields LLMs should expect back. (2) Descriptions are present but often generic and lack context on WHEN to use each tool or dependencies between them. For example, 'Get issues assigned to a user' doesn't explain that get_user must be called first to obtain the accountId. (3) Parameter descriptions lack constraint details, e.g., 'Project key (e.g., "PROJ")' doesn't specify that keys are 2-10 uppercase letters. (4) No error handling guidance is visible, tools have no indication of what failure modes are retryable, user-fixable, or fatal. (5) The update_issue tool uses minProperties constraint but doesn't explain which field combinations are valid or the status transition model. (6) Destructive operations (delete_issue, update_issue) lack confirmation/dry-run patterns despite being dangerous. (7) No idempotency markers are visible on write operations. The baseline for this cohort is strong naming and schema presence (+30 points), moderate descriptions (+20 points), weak output documentation and error guidance (-10 points).
Create a new Jira issue
Create a link between two issues
Delete a Jira issue or subtask
Get issues assigned to a user, with options to filter by assignment status (current, past, or all).
Get a specific Jira issue by key
Get all issues and subtasks for a project or rapid view
Get a user's account ID by email address
Output schemas are not documented in tool definitions. The code implements response sanitization (sanitizeIssuesResponse, deepPruneEmpty) but tool definitions do NOT include outputSchema fields. LLMs cannot predict what data to expect, forcing them to reason about response structure on-the-fly and risking field extraction errors.
Tool dependencies are undocumented. For example, get_assigned_issues requires an accountId parameter, but the description does not say 'call get_user() first' or explain that accountId comes from that tool. Similarly, create_issue expects issueType but doesn't hint that list_issue_types should be called first. This forces LLMs to discover the dependency chain via trial-and-error instead of explicit guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List all available fields in the Jira instance
List all available issue types
List all available issue link types
Update an existing Jira issue
No error handling guidance. Tool descriptions do not explain what to do if a resource is not found, a transition fails, or a permission is denied. For example, delete_issue has no note about 'Issue not found' or 'Permission denied' error modes. Error responses from the Jira API are not caught and re-shaped with actionable guidance per pattern:recovery-guide.
Destructive operations (delete_issue, update_issue) lack confirmation/dry-run patterns. Per pattern:confirmation-request, irreversible operations should support a confirmation step. Agents make mistakes, delete_issue should require explicit approval or offer a dry-run flag before executing.
Parameter descriptions lack constraint details. For example, 'projectKey' is described as 'Project key (e.g., "PROJ")' but doesn't specify format (2-10 uppercase letters, no special chars). 'email' in get_user has no format hint. 'status' in update_issue says 'New status name' but doesn't list valid values or explain the transition model. Per pattern:constrained-input, constraints should be explicit in descriptions, not just in JSON Schema.
No idempotency markers or guarantees on write operations. Agents retry on ambiguous failures, without explicit idempotency guarantees, create_issue or create_issue_link could result in duplicate entries. Per pattern:idempotent-operation, write tools should declare idempotency or document non-idempotent behavior.
Response sanitization is implemented but not transparent. The sanitizeIssuesResponse function in code prunes empty fields, reshapes the response, and selects specific fields, but this behavior is invisible in the tool definitions. LLMs cannot predict what fields will be present or absent, leading to failed extractions and wasted reasoning cycles.