Loading ToolBench
Model Context Protocol server for Jira integration
The server defines 4 tools (list, read, update, delete) with basic schemas and descriptions present, but multiple critical quality gaps reduce the score significantly. All tools have descriptions and input schemas with type information, which is a baseline. However, descriptions are generic and lack clarity on when to use each tool vs. alternatives. Parameter descriptions are minimal and lack constraints. Output schemas are undocumented. Error handling does not guide recovery. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite tools having clear risk profiles. The naming is adequate (verb_noun pattern) but the overall schema completeness and parameter validation guidance is weak. This is typical of a functional but unpolished community server.
Delete a Jira issue. Permanently removes the specified issue from Jira.
List Jira issues with pagination support. Searches issues using JQL query and returns paginated results with issue resources.
Read a single Jira issue by URI. Retrieves detailed information about a specific issue.
Update a Jira issue. Modifies the specified issue with provided data and returns the updated issue.
No output schema documentation. Callers cannot infer what fields are returned or how to chain tools. The mapToResource function is visible in code but not documented in the tool's response contract.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). The 'delete' tool is destructive but has no annotation to warn agents. The 'list' and 'read' tools are read-only but unmarked. This forces LLMs to infer risk from descriptions alone.
Parameter descriptions lack constraints and validation guidance. 'page' parameter has no min/max; 'limit' has a default of 50 but no stated bounds. 'query' (JQL) has no format guidance or examples of valid JQL syntax. 'data' object in update tool has no schema specification for allowed fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
Error handling does not guide recovery. Code throws generic errors like 'URI is required' and 'Invalid resource URI' but does not suggest next steps (e.g., 'Call list() to find valid issue URIs'). No distinction between retryable vs. fatal errors.
Destructive operation (delete) lacks confirmation/dry-run pattern. An agent can call delete without any confirmation step, risking accidental issue deletion. No undo mechanism offered.
Description for 'delete' tool is minimal (18 characters: 'Delete a Jira issue. Permanently removes the specified issue from Jira.'). This is below the 50 - 200 character range recommended for LLM clarity. It states WHAT happens but not WHEN to use it or consequences.
Update tool's 'data' parameter is an untyped object with no schema. Description says 'Object containing fields to update on the issue' but does not specify which fields are allowed, their types, or validation rules. This invites invalid payloads and LLM guessing.
No pagination documentation in 'list' tool description. While parameters include 'page' and 'limit', the description does not explain pagination behavior, what 'page' numbering starts at, or whether 'total' is included in response. Agents cannot plan multi-page retrieval without guessing.