Loading ToolBench
Model Context Protocol (MCP) server for JIRA integration
This server has 2 tools with basic structure but significant quality gaps. Both tools have acceptable names (verb_noun pattern) and non-empty descriptions, but descriptions are extremely terse (17-24 chars, below the 34 char p10 baseline for production tools). Input schemas are present with basic type info, but parameter descriptions are minimal or absent. Output schemas are not documented. No error handling guidance, no pagination support despite search_jira_issue returning potentially large result sets, and no documentation of what fields are actually returned. The code shows JIRA API integration with proper authentication and error handling internally, but the tool interface itself is underspecified for LLM interaction.
Get detailed information about a JIRA issue by its key.
Search for JIRA issues using JQL (JIRA Query Language).
Tool descriptions critically short (17-24 chars vs 34-392 baseline). 'Get detailed information about a JIRA issue by its key' (17 chars) lacks context for when to use this tool vs search_jira_issue. Missing: what fields are returned, when to call this vs search, example use cases.
No output schema documented for either tool. LLMs cannot plan downstream operations or extract fields without knowing what fields are returned. Code shows internal Markdown formatting (summary, description, status) but this is not exposed in the tool definition.
search_jira_issue accepts a free-form JQL query string with no constraints, validation guidance, or examples in the description. LLMs unfamiliar with JQL will hallucinate invalid queries. Parameter description says 'The JQL query string (e.g., "project = MYPROJECT AND status = Open")' but example values in descriptions are an anti-pattern per the rubric, this teaches LLMs to copy literal values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
No pagination or result limit handling for search_jira_issue. JQL searches can return hundreds or thousands of issues. Code provides no limit, offset, or page_size parameters, and no documentation of max result count returned. This violates the pattern:paginated-result rule that tools returning lists must accept limit and provide pagination.
get_jira_issue accepts issue_key parameter that 'Can be a single key or comma-separated keys' but no schema enforces this. Parameter type is string with no pattern, length limits, or format guidance. How does the tool actually parse comma-separated input? Is it actually supported or is this aspirational?
No error handling guidance in tool descriptions. What happens if issue key is invalid? If JIRA API returns 403 (permission denied)? If the query is syntactically invalid JQL? Descriptions must include recovery hints per pattern:recovery-guide.
Parameter descriptions are minimal. 'issue_key' param has decent description but 'query' param for search tool is only 'The JQL query string (e.g., "project = MYPROJECT AND status = Open")', 57 chars, at the low end. Should explain JQL syntax, valid operators, how to structure complex queries, or link to JIRA documentation.