Loading ToolBench
A comprehensive MCP server for Jira integration reproducing Dust implementation
The Jira MCP server has 21 tools with mostly present descriptions and schemas, but several critical gaps emerge. Naming is generally action-verb compliant (get_, create_, update_, delete_, search_, list_), and most tools have descriptions. However, parameter descriptions are inconsistently applied: many parameters lack descriptions entirely or are extremely minimal. Schema definitions exist but are sometimes vague (e.g., 'customFields' in jira_create_issue is {type: 'object'} with no field detail). Output schemas are not documented in the code. Error handling is present (via normalizeError) but guidance is minimal. High-risk tools like jira_delete_issue_link and jira_update_issue lack explicit confirmation patterns. Several tools have overly broad input types (e.g., 'filters' in jira_get_issues is an array of generic objects). Parameter naming inconsistencies exist: some tools accept 'nextPageToken', others reference 'startAt', this will confuse LLMs about pagination behavior.
Add a comment to a Jira issue
Create a new Jira issue
Create a link between two Jira issues
Delete a link between two Jira issues
Get all comments about a specific Jira issue
Get information about the current Jira connection and user
Get all available fields for a Jira project or issue type
Parameter descriptions missing or minimal across multiple tools. Many parameters (e.g., 'expand' in jira_search_issues, 'customFields' in jira_create_issue, 'files' in jira_upload_attachments) lack descriptions or have generic descriptions that don't explain format, constraints, or valid values.
Vague input schemas for complex parameters. 'customFields' is typed as {type: 'object'} with no shape documentation. 'filters' in jira_get_issues is 'array of objects' with no field definitions. 'files' in jira_upload_attachments is 'array of objects' with no structure. LLMs cannot infer the correct payload structure from these vague schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Get detailed information about a specific Jira issue
Get available issue link types
Get all available issue types in Jira
Search issues using one or more filters (e.g., status, priority, labels, assignee, fixVersion, customField, dueDate, created, resolved). Use exact matching by default, or fuzzy matching for approximate/partial matches on summary field. For custom fields, use field 'customField' with customFieldName parameter. For date fields (dueDate, created, resolved), use operator parameter with '<', '>', '=', etc. and date format '2023-07-03' or relative format like '-25d', '7d', '2w', '1M', etc. Results can be sorted using the sortBy parameter with field and direction (ASC/DESC).
Search JIRA issues using a custom JQL (Jira Query Language) query. This tool allows for advanced search capabilities beyond the filtered search. Examples: 'project = PROJ AND status = Open', 'assignee = currentUser() AND priority = High', 'created >= -30d AND labels = bug'.
Get all available Jira projects
Get available transitions for a Jira issue
Get summaries of all fields in a Jira project
Get a list of users in a Jira project or instance
Search for Jira issues using various filters or JQL
Search for Jira users by exact email address
Transition a Jira issue to a different status
Update an existing Jira issue
Upload attachments to a Jira issue
Output schemas not documented in tool registrations. Tool descriptions do not specify what fields are returned or their types. LLMs cannot plan downstream calls or extract the right data without knowing response structure.
Pagination parameter inconsistency. Some tools accept 'nextPageToken' (jira_get_issues_using_jql), others reference 'startAt' (jira_search_issues). Code comments note 'Support both for backward compat', but this forces LLMs to reason about two different pagination styles and risks confusion about which tool accepts which pagination form.
Destructive tool jira_delete_issue_link lacks confirmation pattern. Tool can permanently delete links between issues with only a linkId parameter. No dry-run, no confirmation step, no recovery guidance. Per pattern:confirmation-request, irreversible operations should support user confirmation.
Error handling guidance is minimal. Code invokes normalizeError() but actual error messages returned to LLMs are not shown. No evidence of category classification (retryable vs. user-fixable vs. fatal). No self-correction hints like 'Try search_users() with a partial name.'
Tool jira_get_issues uses generic filter parameter structure without clear documentation of supported filter types. Description mentions 'status, priority, labels, assignee, fixVersion, customField, dueDate, created, resolved' but schema does not validate that filters conform to these types. LLMs may pass invalid filter combinations.
Overlapping tool functionality without clear disambiguation. jira_search_issues, jira_search_issues_using_jql, and jira_get_issues all perform issue searches with different interfaces and parameter names. Descriptions do not clearly state when to use which tool, LLMs will struggle to pick the right one.
Parameter naming inconsistency in resource identifiers. Some tools accept 'issueKey', others use 'projectKey'. No consistent pattern for when to use key vs. ID. jira_get_fields requires both projectKey and issueType but description does not state whether both are required or one is optional.
No documented return field guarantees for chaining. If jira_create_issue returns an issueKey, tool definitions should promise that field in the response. Similarly, if jira_get_issue is called after creation, the return must include issueKey so it can be passed to jira_create_comment. No response schema documentation means LLMs cannot rely on field presence.