A lightweight, native Go CLI and MCP server for self-hosted Atlassian Jira and Confluence Server/Data Center instances
Server has 16 tools with consistent naming (verb_noun pattern) and basic descriptions. All tools have input schemas with type definitions and parameter descriptions. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. Missing tool annotations (readOnlyHint, destructiveHint). Parameter descriptions lack format constraints and validation rules. No pagination support documented for list operations.
Add labels to a Confluence page
Add a restriction to a Confluence page
Get a Confluence page by ID, including its content
List labels on a Confluence page
List restrictions on a Confluence page
Remove a label from a Confluence page
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure.
Tool descriptions lack LLM-optimized guidance. Generic descriptions like 'Get a Jira issue' do not explain WHEN to use this tool vs. jira_search_issues, or what fields are returned. Descriptions should be 50-200 chars and answer: what, when, and what's returned.
Missing tool annotations. Destructive tools (jira_delete_issue, confluence_remove_label, confluence_remove_restriction) lack destructiveHint annotation. Read-only tools lack readOnlyHint. Agents need these hints to reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Remove a restriction from a Confluence page
Create a new Jira issue
Delete a Jira issue
Get a Jira issue by key, including summary, description, status, assignee, and other fields
Get the currently authenticated Jira user
Get subtasks of a Jira issue
Get available transitions for a Jira issue
Search Jira issues using JQL query language
Transition a Jira issue to a new status
Update fields on an existing Jira issue
Parameter descriptions lack format constraints and validation rules. E.g., 'jql' parameter has no guidance on valid JQL syntax. 'max_results' has no min/max bounds. 'priority' and 'issue_type' have no enum values. Constraints should be explicit in descriptions or JSON Schema.
No error handling guidance. Tools return raw errors with no recovery hints. E.g., if jira_get_issue fails with 'issue not found', the LLM has no guidance to try jira_search_issues. Error responses should categorize as retryable/user-fixable/fatal and suggest next steps.