Loading ToolBench
MCP server providing tools for interacting with Atlassian Confluence and Jira Cloud APIs
This C+ server has moderate definition quality with consistent naming conventions and descriptions, but exhibits significant gaps in schema completeness, parameter type definitions, and error handling patterns. All 13 tools follow verb_noun naming (confluence_*, jira_*), which is correct. Descriptions are present for all tools and most parameters, ranging 60-280 characters, solid baseline. However, schema documentation is incomplete: input parameters lack formal type declarations in the visible source (descriptions mention types but JSON Schema types are not explicitly visible in the rubric data), and output schemas are minimally documented. Error handling is sparse, no recovery guidance, no actionable error messages, no dry-run/confirmation for destructive operations. The upsert_page tool shows input validation (line checks for required fields) but most tools lack this. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having 8 READ_ONLY, 2 WRITE, and 1 DESTRUCTIVE operations declared in the risk matrix.
Get a Confluence folder by id (REST v2).
Get a Confluence page by id (REST v2).
Get the homepageId for a Confluence space key (REST v2).
Get space info for a Confluence space key (REST v2): spaceId + homepageId.
List Confluence spaces (REST v2). Optionally filter by comma-separated keys.
List ONLY root-level folders (type=folder) for a Confluence space. Handles folder/page homepage fallback.
Create or update a Confluence page (REST v2). If page_id is empty => create under parent_id (or homepageId if parent_id is empty). If page_id is provided => update that page (auto increments version.number). To reference a Jira issue in body_storage_html, use the Jira macro: <ac:structured-macro ac:name="jira"><ac:parameter ac:name="key">KEY</ac:parameter></ac:structured-macro>.
Input parameter schemas lack formal JSON Schema type declarations. Source shows parameter descriptions include type hints (e.g., 'integer', 'string', 'boolean') but the actual JSON Schema structure and constraints (min/max, pattern, enum) are not visible or not enforced. This violates the 'constrained-input' pattern and leaves parameter validation to the LLM.
Output schemas are not documented. Tools return JsonElement (C#) but LLMs receive no schema specification for response structure. For example, confluence_list_spaces response format is unknown, does it return an array? An object with 'spaces' field? What fields are in each space? This forces LLMs to reason blindly about response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Create a Jira issue (REST v3 POST /issue). Description is plain text converted to ADF. Returns {id,key,self}.
Delete a Jira issue (REST v3 DELETE /issue/{issueIdOrKey}). Optionally delete subtasks.
Get a Jira issue by id or key (REST v3).
Get a Jira project by id or key (REST v3).
List Jira projects (REST v3). Supports optional query + pagination.
Search Jira issues using POST /rest/api/3/search/jql (scoped token). Pagination uses nextPageToken only.
No tool annotations despite having destructive (jira_delete_issue) and write operations (confluence_upsert_page, jira_create_issue). The MCP spec supports readOnlyHint, destructiveHint, and idempotentHint to guide LLM behavior and tool selection. Absence of these annotations means LLMs cannot distinguish safe tools from destructive ones at selection time.
Error handling does not provide recovery guidance. The source shows only ArgumentException for validation in confluence_upsert_page; no other tools show try-catch blocks or error transformation. If a Jira API call fails with 'Cannot delete issue: has subtasks', the LLM receives a raw error with no guidance on whether to retry, use jira_delete_issue with delete_subtasks=true, or ask the user. This violates the 'recovery-guide' pattern.
Destructive tool (jira_delete_issue) lacks confirmation/dry-run support. LLMs can call this directly with no chance to review. Best practice: offer a dry-run parameter or a separate 'preview_delete_issue' tool that shows what would be deleted and requires explicit confirmation.
Parameter limit defaults are not bounded. jira_list_projects has 'max_results' with description 'default 50, max 200' but no schema enforcement. If LLM passes max_results=10000, the tool may fail or timeout silently. Schema should include explicit 'maximum': 200 and 'minimum': 1.
Some parameter descriptions are vague or lack expected format/constraint guidance. E.g., jira_get_issue 'fields_csv' says 'Optional fields CSV, e.g. summary,status,assignee' but does not specify max length, valid field names, or pattern. confluence_upsert_page 'body_storage_html' requires storage format (XML-like tags) but description does not explain this clearly, a novice LLM may pass plain HTML.
confluence_upsert_page has complex interdependent parameters (page_id determines CREATE vs UPDATE; parent_id only used on CREATE) but documentation does not explicitly state mutual exclusivity. Descriptions should say: 'Provide EITHER page_id (to update) OR parent_id + title (to create). If both page_id and parent_id are provided, parent_id is ignored.'
No batch operations for multi-item actions. If an LLM needs to delete 10 issues, it must call jira_delete_issue 10 times sequentially. A batch variant (jira_delete_issues with issue_id_or_key array) would reduce token overhead and latency.