Loading ToolBench
Model Context Protocol server providing read-only access to Jira issues, projects, comments, worklogs, and transitions
Six read-only tools with consistent naming (verb_noun pattern: jira_get_*, jira_search_*). All tools have descriptions (194 - 250 chars, within baseline 34 - 392 range) and input schemas with typed parameters. However, output schemas are NOT documented, LLMs cannot predict response structure for downstream chaining. Parameter descriptions are present but lack format constraints (e.g., 'issueKey' should specify format 'PROJ-123' or regex). Error handling is present (JiraNotFoundException, JiraAuthenticationException, etc.) but error messages are generic ('Jira request failed') rather than actionable recovery guidance. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Pagination is implemented (maxResults, startAt) but total count is not documented in output. Tool composition is sound, each tool has one responsibility.
Retrieve detailed information about a Jira issue/ticket using its issue key, such as SH-820 or PROJ-123. Use this when you need to understand the issue's summary, description, status, assignee, reporter, creator, priority, issue type, labels, components, dates, parent issue, epic, story points, time tracking, and other available metadata.
Retrieve comments for a specific Jira issue/ticket using its issue key (e.g. 'SH-820'). Returns the list of comments with comment ID, author, creation date, updated date, and comment body rendered in readable markdown format.
Retrieve available workflow transitions for a specific Jira issue/ticket using its issue key (e.g. 'SH-820'). Returns the list of transitions with transition ID, name, target status, and metadata.
Retrieve worklog entries for a specific Jira issue/ticket using its issue key (e.g. 'SH-820'). Returns the list of worklogs with worklog ID, author, time spent, dates, and optional comment.
Retrieve details of a Jira project using its project key (e.g. 'SH', 'PROJ') or project ID. Returns project key, ID, name, description, project lead, project type, category, and URL.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects) for downstream tool chaining. E.g., jira_get_issue returns JSON but no schema is visible in code or docs.
Parameter format constraints missing. 'issueKey' accepts 'PROJ-123' or 'SH-820' but no regex or format is specified. LLMs may pass invalid formats like 'proj-123' or 'PROJ_123'.
Error messages are generic and non-actionable. 'Jira request failed: {ex.Message}' does not guide LLM recovery. Should include: error category (retryable vs user-fixable), suggested next step, and invalid value if applicable.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | <=2025-11-25 | v2 |
Search for Jira issues using Jira Query Language (JQL). Returns a concise list of matching issues with essential fields including key, summary, status, priority, issue type, assignee, reporter, and dates. Use this to find issues by project, status, assignee, text search, or custom JQL filters.
No tool annotations despite all tools being read-only. McpServerTool attribute has ReadOnly=true but no formal annotation in schema. LLMs cannot infer safety without explicit readOnlyHint.
Pagination response does not document total count or next_cursor. jira_search_issues accepts maxResults and startAt but response structure is opaque, LLM cannot determine if more results exist.