Loading ToolBench
MCP server for Jira Cloud REST API integration
Server has 13 well-named tools with complete Zod schemas and descriptions. Naming follows verb_noun convention (get_issue, create_issue, search_issues, etc.). All tools have descriptions (avg ~100 chars). Schemas are properly typed with Zod. However, parameter descriptions are sparse or missing context about constraints, formats, and dependencies. Output schemas are not documented, LLMs cannot predict response structure. Error handling returns raw HTTP errors without recovery guidance. No tool annotations (readOnlyHint, destructiveHint). Missing idempotency guidance for write operations. Some parameters like 'fields' and 'expand' accept unions but lack format examples or constraints.
Upload an attachment to an existing issue
Add a plain-text comment to an existing issue
Create a Jira issue with arbitrary fields and update payloads
Delete an attachment by attachment id
Fetch attachment metadata by attachment id
Fetch a Jira issue with selectable fields and raw metadata
Inspect field metadata, createmeta, editmeta, and transitions for an issue or project/issue type pair
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects). Forces agents to guess what data is available after each call.
Error handling returns raw HTTP errors without recovery guidance. 'HTTP 400: {...}' tells LLM nothing about what went wrong or how to fix it. Missing actionable error messages.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes. delete_attachment and update_issue lack explicit destructive/write markers.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Get sprint info and its issues for a given board ID
List all Jira projects accessible with the current credentials
Send an authenticated request to Jira Cloud REST APIs as an escape hatch for unsupported endpoints
Search Jira issues using JQL with selectable fields and raw response access
Transition an issue explicitly, optionally setting fields in the same request
Update arbitrary fields or transition an issue
Parameter descriptions lack format constraints and examples. 'fields' and 'expand' accept unions but no guidance on valid values, format, or when to use each. 'jql' parameter has no JQL syntax hints.
search_issues and list_projects lack pagination guidance. No maxResults default, no total count in response, no next_cursor. Large result sets risk context window exhaustion.