atlassian-readonly
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NODE_OPTIONS | No | Node.js options, e.g., --use-system-ca to trust corporate certificates. | |
| NODE_EXTRA_CA_CERTS | No | Absolute path to a non-expired corporate CA certificate in Base-64 PEM format. | |
| ATLASSIAN_USER_EMAIL | Yes | The Atlassian account email address that created the API tokens. | |
| ATLASSIAN_JIRA_API_TOKEN | No | Jira API token (for process-scoped CI use). | |
| ATLASSIAN_JIRA_TOKEN_FILE | No | Path to a file containing the Jira API token (for headless systems). | |
| ATLASSIAN_CONFLUENCE_API_TOKEN | No | Confluence API token (for process-scoped CI use). | |
| ATLASSIAN_CONFLUENCE_TOKEN_FILE | No | Path to a file containing the Confluence API token (for headless systems). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| jira_get_issueA | Read one Jira issue. This server has no write operations. |
| jira_search_issuesB | Search Jira with JQL. Results and fields are bounded; this server has no write operations. |
| confluence_get_pageA | Read a Confluence page by ID and convert storage HTML to Markdown. This server has no write operations. |
| confluence_searchA | Search Confluence with CQL. Results are bounded; this server has no write operations. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: get versus search for both Jira and Confluence. There is no overlap or ambiguity between any pair, enabling precise tool selection.
All tool names follow a consistent product_action pattern with snake_case (e.g., jira_get_issue, confluence_search). The naming is uniform and predictable.
With 4 tools covering two products (Jira and Confluence) each having a get and search operation, the count is well-scoped for a read-only server. No tool feels redundant or missing.
The read-only surface provides essential get and search for both products. Minor gaps exist such as bulk fetch or additional metadata endpoints, but core querying needs are well covered.