Loading ToolBench
MCP server for querying Jira issues and retrieving issue details
jira-query-mcp provides two read-only Jira tools with basic schemas and descriptions. Naming follows verb_noun convention (get_jira_issue, get_jira_issues). Input schemas are present with proper JSON Schema structure and parameter descriptions. However, output schemas are completely undocumented, the code returns large JSON structures but does not describe what fields agents should expect. Parameter descriptions are minimal (10-30 chars), falling below the baseline of 72 chars for production tools. No parameter validation constraints (enums, ranges) are declared. Error handling is basic (HTTP status thrown as generic error) with no recovery guidance. The tools lack pagination limits documentation despite potentially returning hundreds of issues. No tool annotations (readOnlyHint, idempotentHint) are present despite these being read-only operations.
Get a specific Jira issue by key
Get all issues and subtasks for a Jira project
Output schemas completely undocumented. Code returns multi-field JSON objects (issue metadata, attachments, comments, subtasks) but tool definitions provide no schema documentation for what fields agents should expect or how to extract downstream values.
Parameter descriptions are too brief (10-30 chars). Baseline for production is 72 chars. 'Project key (e.g., "PP")' and 'The Jira issue key (e.g., PROJ-123)' lack context on format constraints, valid character ranges, or when to use each tool instead of a similar one.
No pagination documentation or limits. get_jira_issues can return hundreds of results with no stated cap. Code returns startAt, maxResults, total fields but tool description does not mention pagination, offset/limit params, or result limits.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
No input validation constraints declared. The 'jql' parameter accepts free-form strings with no validation, validation bounds, or error guidance. LLMs can pass malformed JQL which fails silently at the API layer.
Error handling provides no recovery guidance. Generic 'HTTP 401: Unauthorized' or 'HTTP 404: Not Found' errors are returned as-is with no hints: 'Check JIRA_API_TOKEN and JIRA_HOST environment variables' or 'Try searching with a different issue key or project name'. Pattern:recovery-guide requires errors to tell the agent what to do next.
No tool annotations (readOnlyHint, idempotentHint) declared despite both tools being read-only and idempotent. Annotations help agents distinguish safe tools from destructive ones and support optimizations like result caching.
Tool description for get_jira_issues does not explain the relationship between 'projectKey' and optional 'jql' parameter. The implementation concatenates them ('project = XX AND custom JQL') but the description does not clarify that jql is an AND filter, not a replacement.