Loading ToolBench
MCP server providing tools for Atlassian Confluence and Jira integration, enabling retrieval of pages, issues, comments, attachments, and related content
The Confluence Assistant MCP provides 9 read-only tools with basic to adequate schema definitions and descriptions. All tools follow a clear verb_noun naming pattern (getPageById, searchPagesByTitle, etc.), which is positive. However, several critical gaps undermine production readiness: (1) Output schemas are completely undocumented, no tool declares what fields or structure is returned, forcing LLMs to infer results; (2) Parameter descriptions are present but generic and lack actionable constraints (ranges, enums, formats); (3) Error handling is centralized in a try-catch but provides only HTTP status codes without recovery guidance; (4) No pagination details are documented despite tools accepting limit/start parameters; (5) Authentication is via environment variables (good practice) but the tool descriptions do not explain prerequisites or common failure modes. The server landed in the C/D range typical of community tools, functional but lacking LLM optimization.
Get all issues in the current active sprint for a given Jira board
Get a Jira issue by its key
Get attachments on a Confluence page
Get a Confluence page by its ID
Get comments on a Confluence page
Find related issues for a given Jira issue
Find pages that are topically related to a given page
No output schemas documented. Tools return JSON.stringify() results but LLMs cannot predict structure, field names, or types. This breaks downstream tool chaining and forces LLMs to guess at response formats.
Parameter descriptions lack actionable constraints. 'Maximum number of results to return, default is 25' does not state the valid range (1-100? 1-500?). LLMs cannot validate inputs proactively.
Error handling provides HTTP status codes but no recovery guidance. A 404 error returns 'The requested Confluence resource could not be found' without suggesting next steps (e.g., 'try searchPagesByTitle() with a partial match').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Get all issues in a sprint, optionally filtered by a list of issue types
Search for Confluence pages by title
Pagination parameters (limit, start) are present but not documented as part of a pagination pattern. No mention of total counts, next_cursor, or what happens when results exceed the limit.
Tool descriptions are generic and under 100 characters in most cases. No context on WHEN to use each tool vs. similar tools (e.g., when to call getRelatedPages vs. searchPagesByTitle). LLMs cannot disambiguate.
expand parameter (array of strings) has no enum constraints or examples of valid values. LLMs may pass invalid field names like 'invalid.field' without warning.
SimplePageResult returned by getPageById is inferred from code inspection (src/index.ts) rather than formally documented in the tool's output schema. Cannot verify it includes all necessary fields for chaining (e.g., space key, parent page ID).