MCP Atlassian

In the scored setup the server signs every Jira and Confluence call with the one API token or personal access token the user puts in its environment. Atlassian API tokens carry the user's full access to both products, and the server does no per-tool or per-request authorization of its own, so whatever the user can read or change, the connected model can too. OAuth 2.0 is an opt-in alternative that asks for named scopes (by default read and write on Jira work plus Confluence space summaries), but read and write still share one grant. The opt-in HTTP transport supports per-user tokens supplied in request headers; that mode was not the scored default.

As a tool server, this project leaves approval to the MCP host, and what it gives the host is good risk signalling: all 98 tools are split into separate read and write tools, every read tool is marked read-only and every write tool carries a destructive or non-destructive hint. A server-enforced read-only mode removes write tools both from the listing and at call time, and every write tool also checks it. There is no preview or dry-run for destructive operations except a validate-only option on batch issue creation, and the read-only mode is off by default. Deleted Jira issues and sent comments or notifications cannot be undone.

Tools are narrow, purpose-built Jira and Confluence operations (create issue, add comment, update page) with typed arguments, issue-key patterns and bounded page sizes on most list tools, rather than a generic HTTP or query passthrough for writes. The few tools that read local files (attachment upload and page content from a file) resolve the path, following symlinks, and refuse anything outside the server's working directory. Search tools pass the model's JQL or CQL to Atlassian unchanged, and the issue search accepts any result limit. In the scored setup every toolset is enabled, including all write tools, and optional project and space filters are off, so a misused tool can act anywhere the user's account reaches.

The server has no code-execution path: it makes HTTP calls to Atlassian and converts content between Markdown and Atlassian formats, and nothing in the source runs a shell, spawns a process, or evaluates model-supplied code. JQL and CQL strings are sent to Atlassian's search APIs, which interpret them server-side as read-only queries.

Issue descriptions, comments, Confluence pages and service-desk requests are written by many people, including external customers, and the server returns them to the model as JSON fields alongside metadata, with no marker saying which text is untrusted. Tool descriptions and server instructions are plain and contain no directives aimed at the model. In the scored setup the same session can read that content, read private data across the user's Jira and Confluence, and write, comment, delete or upload local files, and nothing in the server breaks that combination; the read-only mode that would remove the write leg is off by default. A successful injection can therefore leak private data into a page or comment and take irreversible actions without any human step the server enforces.

The server keeps no memory between calls and loads no instruction files. Its only auto-loaded configuration is a .env file, which python-dotenv looks for starting from the installed package's own directory (for the README's uvx install, a user cache path) rather than the current project, and the server's tools cannot write local files (attachment downloads are returned inline). Nothing the model reads can therefore persist into later sessions through the server.

The server loads no plugins, MCP servers, downloaded tools or model files at runtime. The only dynamic import is an opt-in OAuth-proxy storage backend whose module path the operator sets in an environment variable, which is operator configuration rather than an extension the model or content can add.

Credentials come from environment variables (or the MCP host's config file), OAuth tokens are kept in the OS keyring with a 0600 file fallback, and the code masks tokens and authorization headers wherever it logs them. There is no telemetry or crash reporting. Credentials never enter tool results, but Jira and Confluence content returned to the model is not scanned for secrets, and error text from failed calls is passed back to the model as is. The default API token is long-lived and covers the user's whole Jira and Confluence access.

The server keeps no audit record of what it did. Logs go to standard error at WARNING level by default, so successful tool calls (creates, updates, deletes) are not recorded at all; only failed calls and warnings appear, as unstructured text. Raising verbosity adds informational lines for some operations, but there is no structured per-call record, no actor attribution and no durable storage; the MCP host's own logs are not credited.

The server bounds some of its own work: every Atlassian HTTP call has a 75-second timeout by default, inline attachments are capped at 50 MB, and most list tools cap page size at 50. Retries, a concurrency cap, an outbound rate limit, a circuit breaker and a pagination ceiling all exist but are off by default. The issue search accepts any limit and pages until it is reached, and attachments are read fully into memory before the size check. When the host process exits, the stdio server notices and cancels its main task, though synchronous HTTP calls already in flight run to their timeout.