MCP server for Atlassian Confluence and Jira integration
The Atlassian MCP server has moderate definition quality with significant gaps. Tool naming follows verb_noun conventions (get-, create-, update-, delete-, search-, list-) which is good. However, descriptions vary widely in quality: some are adequately detailed (e.g., 'confluence_search' with CQL context), while others are minimal or generic (e.g., 'health' with empty input). Parameter schemas are present and use Zod validation with type annotations, but many parameters lack detailed descriptions explaining constraints, formats, or dependencies. Parameter descriptions average 15-40 characters, well below the 72-character baseline for A+ tools. Output schemas are not explicitly documented, responses are formatted as text blocks in JSON rather than structured typed objects. Error handling is minimal; there's no evidence of recovery guidance, error categorization, or actionable error messages. The 'create-jira-issue' and 'update-jira-issue' tools are marked WIP, indicating incomplete implementation. Overall, this server would be usable but would benefit from richer descriptions, documented output schemas, and better error handling.
Advanced Confluence search using CQL (Confluence Query Language)
(WIP) Create a new Jira issue. This tool is a work in progress and may not be fully functional yet.
Create a new Confluence page
Delete a Jira issue by key
Delete a Confluence page by ID
Get children of a Confluence page by ID
Parameter descriptions are minimal and lack constraint information. Examples: 'limit' described only as 'limit' (8 chars), 'start' as 'start' (5 chars), 'status' as 'Page status (default: current)' (28 chars). LLMs cannot infer valid ranges, formats, or dependencies from such brief descriptions.
No output schema documentation. All tools return responses formatted as generic text in JSON objects with type='text', not structured typed objects. LLMs cannot plan downstream tool calls or extract specific fields because return schema is not documented. Example: get-page returns title and URL as concatenated text, not as separate fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Get a Confluence folder by ID
Get a Jira issue by key. Returns issue details including description and subtasks.
Get a Confluence page by ID (optionally specify content format: storage or markdown)
Get a Confluence space by ID
Health check for integration testing
List all Confluence spaces (optionally filter by keys)
Search Jira issues using JQL
(WIP) Update a Jira issue by key. This tool is a work in progress and may not be fully functional yet.
Update a Confluence page by ID
Two write tools marked WIP with reduced descriptions: 'create-jira-issue' and 'update-jira-issue' have description '(WIP) ...' and are noted as 'may not be fully functional yet.' These should either be completed, hidden, or removed. Incomplete tools break agent workflows.
No error handling or recovery guidance in tool implementations. When resources are not found (e.g., 'Space with key not found'), the response is a plain text message, not a structured error with suggestions for alternatives or next steps. Agents receive no guidance on what to do next.
No confirmation or dry-run support for destructive operations (delete-page, delete-jira-issue). Agents can invoke these without verification, risking data loss. No evidence of a confirmation_before_execute pattern.
Credentials (ATLASSIAN_BASE_URL, ATLASSIAN_API_TOKEN, ATLASSIAN_USERNAME) are injected via environment variables, which is correct. However, no evidence that credentials are validated, rotated, or that tool responses filter sensitive data (e.g., session tokens, internal IDs). Responses should be audited to ensure no secrets are leaking.
No pagination support documented or implemented. search-jira-issues accepts nextPageToken and maxResults, but responses do not indicate whether results are truncated or how to fetch the next page. confluence_search accepts limit and start but no total count or next_cursor is returned. Large result sets risk context window exhaustion.
Tool composition and chaining risk. For example, create-page requires spaceKey but then looks up spaceId internally via listSpaces. If listSpaces fails or returns multiple results, the behavior is unclear. Parameters should expose IDs directly (spaceId) alongside human-friendly names (spaceKey) as separate optional parameters, not force internal lookup.
health tool has a trivial description ('Health check for integration testing') and serves no user-facing purpose. It should be removed or hidden from the exposed tool set to avoid clutter in agent decision-making.