Labsco
MCP SERVER

Atlassian

by sooperset ↗

Run Jira and Confluence from one place — issues and sprints, service desk queues, pages, attachments and permissions.

Project & Task Management✓ Official source
Summary
Sprint admin and the writing-up afterwards stop being two tools and two tabs.

One session can query issues in JQL, move them into a sprint, then write the result into a Confluence page — updating a single section rather than replacing it. The reporting that usually needs a plugin is answered directly: SLA metrics, cross-project dependencies, and the pull requests linked to an issue.

What it is

98 tools across both products, for Cloud and for Server and Data Center. Jira covers issues, JQL search, transitions, boards and sprints, worklogs, versions, service desk, ProForma forms, SLA metrics and development links; Confluence covers pages, templates, comments, attachments, restrictions and space permissions.

What you get
  • Jira issues searched by JQL, fetched with their enrichments, created singly or in batches, updated, assigned, transitioned, linked, moved between projects and deleted (`jira_search`, `jira_get_issue`, `jira_create_issue`, `jira_update_issue`, `jira_transition_issue`)
  • Boards and sprints handled end to end: sprints created and updated, issues added to a sprint or sent back to the backlog, board and sprint issues listed
  • The project metadata a create screen depends on — issue types, create fields, field options, components and fix versions
  • Service desk work: queues, request types and their field definitions, and customer requests raised on someone else's behalf
  • Delivery signal read off the issue: date and status-change history, SLA metrics such as cycle and lead time, and the pull requests, commits and branches linked to it
  • Cross-project structure: a project's epics grouped under their parents, and every issue link that leaves the project
  • Confluence pages created from scratch or from a template, updated whole or one section at a time, moved, copied, restricted and diffed between versions (`confluence_search`, `confluence_get_page`, `confluence_create_page`, `confluence_update_page`)
  • Confluence comments including inline ones anchored to a text selection, labels, page view statistics and a space's page tree
  • Attachments on both sides: uploaded singly or in bulk, listed, downloaded as embedded resources, and images returned inline
Requirements

Uvx on your PATH — or the `ghcr.io/sooperset/mcp-atlassian` container — and credentials for each product you use. On Cloud that is `JIRA_URL`, `JIRA_USERNAME` and `JIRA_API_TOKEN`, with the matching `CONFLUENCE_*` trio; OAuth 2.0 is also supported. On Server and Data Center it is a personal access token in `JIRA_PERSONAL_TOKEN` or `CONFLUENCE_PERSONAL_TOKEN` instead, with client-certificate variables available for mTLS. Either product can be configured on its own. Supported deployments are Confluence Cloud and Server v6.0+, and Jira Cloud and Server v8.14+. Two settings worth knowing before an agent touches a real instance: `READ_ONLY_MODE` disables every write, and `ENABLED_TOOLS` narrows the surface to a named list. Cloud and Server do not expose the same tools — `jira_move_issue` and `confluence_get_page_views` are Cloud only, and the service desk queue tools are Server and Data Center.

Setup effort

One command plus a key — uvx mcp-atlassian, then supply credentials