MCP server for Atlassian JIRA and Confluence integration
Server has 6 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization) and input schemas with type definitions. However, descriptions lack actionable context (WHEN to use, prerequisites, dependencies). Parameter descriptions are minimal or absent. Output schemas are not documented. Error handling is generic (no recovery guidance, no categorization). No tool annotations (readOnlyHint/destructiveHint). Naming is clear and verb-prefixed, but parameter naming could be more explicit (e.g., 'max_results' vs 'limit' inconsistency across tools).
Add a comment to a JIRA ticket
Create a new JIRA ticket
Get a Confluence page by ID
Get details of a JIRA ticket by key
Search for content in Confluence
Search for JIRA tickets using JQL
Descriptions are too brief (10-50 chars) and lack actionable context. LLMs need WHAT, WHEN, and prerequisites. E.g., 'Get details of a JIRA ticket by key' omits: when to call this vs search_jira_tickets, what fields are returned, whether it requires authentication setup.
Parameter descriptions are missing or minimal. 'ticket_key' has description 'JIRA ticket key (e.g., CPDEV-3371)' but lacks format constraints (length, case, pattern). 'jql' parameter has no description of valid JQL syntax or examples of common queries.
No output schemas documented. LLMs cannot plan downstream calls or extract required fields. E.g., does get_jira_ticket return assignee_id, assignee_name, or both? Does search_jira_tickets return a total_count for pagination?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). create_jira_ticket and add_comment_to_jira_ticket are destructive but unmarked. Agents cannot distinguish safe retry candidates from irreversible operations.
Error handling is generic. Code catches errors and logs them but returns no recovery guidance. E.g., if a ticket key is invalid, the error should suggest 'Try search_jira_tickets() to find the correct key' rather than a raw HTTP error.