Add it with claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2, then run /mcp and complete the OAuth sign-in. It covers Jira, Confluence, Jira Service Management, Bitbucket, and Compass on Atlassian Cloud, and respects the permissions your account already has. OAuth 2.1 and API tokens cover different product sets, and calls are rate limited per hour by plan.
- Current endpoint:
https://mcp.atlassian.com/v1/mcp/authv2. The/v1/sseone is legacy. - Authenticate with
/mcpafter adding. Nothing goes in your config file. - OAuth and API tokens cover different products. Check the matrix before choosing.
- It respects your existing Atlassian permissions. It cannot widen them.
- Cloud only. Data Center and Server are not supported.
- Rate limited per hour, by plan: 500 on Free, 1,000 on Standard and above.
The command
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2
# then, inside a session, complete the browser sign-in
/mcp
Three endpoints exist. Use the first.
| Endpoint | Status |
|---|---|
https://mcp.atlassian.com/v1/mcp/authv2 | Current. Use this |
https://mcp.atlassian.com/v1/mcp | Supported, and the one API-token setups use |
https://mcp.atlassian.com/v1/sse | Legacy. Works, but SSE is deprecated protocol-wide |
claude mcp remove atlassian
claude mcp logout atlassian # drop the old OAuth grant
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2
claude mcp list
OAuth or API token
Two authentication paths, and they are not interchangeable. The product coverage genuinely differs, which is the single most useful thing on this page.
Product coverage by authentication method, from the atlassian/atlassian-mcp-server repository, August 2026.
| Product | Permission groups | OAuth 2.1 | API token |
|---|---|---|---|
| Jira | read, write, search | Yes | Yes |
| Confluence | read, write, search | Yes | Yes |
| Jira Service Management | read, write | No | Yes |
| Bitbucket Cloud | read, write | No | Yes, scoped only |
| Compass | read, write | Yes | No |
| Atlassian platform | read_teamwork_graph, search_atlassian | Yes | Yes |
- OAuth 2.1 is the default and the right choice for a person at a laptop. Browser sign-in, no secret in any file, and every action runs with the permissions your Atlassian account already has.
- API tokens are for headless and service use, and for Jira Service Management or Bitbucket, which OAuth does not cover. They need an admin to enable token access in Atlassian Administration first, and a scoped personal token.
claude mcp list # ! Needs authentication until you sign in
claude mcp login atlassian # run the OAuth flow from the shell
claude mcp login atlassian --no-browser # over SSH: prints the URL instead
claude mcp get atlassian
That --no-browser variant matters more than it sounds. Plenty of people run Claude Code on a remote box over SSH, where the OAuth flow cannot open a browser. It prints the authorisation URL, you open it locally, then paste the full redirect URL back. Connect with ssh -t so the paste prompt has a terminal.
Rate limits and plans
Published on Atlassian's remote MCP server page, read 7 August 2026. Check before you build against them.
| Plan | Calls per hour |
|---|---|
| Free | 500 |
| Standard | 1,000 |
| Premium and Enterprise | 1,000, plus 20 per user, up to 10,000 |
The hourly ceiling is a real constraint for one specific pattern: asking an agent to sweep a board. "Summarise every open ticket in the sprint" is dozens of calls, and on a Free plan a couple of those in an afternoon is the budget gone. Sprint sweeps belong in a search query, not a loop.
What it is actually good for
The value is not that Claude can read a ticket. It is that the ticket, the branch, the diff, and the pull request stop being four windows you are copying between.
Read ENG-4521, then plan the change against this repo before writing anything.
Implement it. Use the acceptance criteria from the ticket as the test cases.
Open a PR, link it to ENG-4521, and move the ticket to In Review with a comment
summarising what changed and what still needs a human decision.
Where it earns its context, and where it does not.
| Task | Worth it? |
|---|---|
| Implementing a well-specified ticket | Yes. The clearest win |
| Writing a release note from closed issues | Yes |
| Finding the Confluence page that explains a decision | Yes |
| Triage: labels, components, duplicate detection | Yes, with care |
| Bulk-editing forty tickets | No. Use the Atlassian bulk tools |
| Reading one ticket you already have open | No. Paste it |
| Anything on Data Center | Not supported |
Confluence is the half people forget
The same server reaches Confluence, and for most teams that is where the answer to "why is it built this way" actually lives. An agent that can search the space before it starts writing produces markedly better plans, because the constraint it would otherwise rediscover by breaking something is written down.
Before you plan this, search Confluence in the ENG space for anything about
rate limiting or idempotency keys, and quote what you find. If there is a
decision record that contradicts the ticket, say so instead of proceeding.
Write access to Confluence is a different risk calculation from write access to Jira. A wrong Jira transition is a two-click undo. A page rewritten in place has a version history that nobody reads. Keep Confluence at read unless the workflow is explicitly about drafting documentation.
Asking for the right thing
The difference between this server being useful and being a rate-limit generator is almost entirely in how you phrase the request. Jira is a query engine with a query language, and an agent handed a vague instruction will fall back to fetching things one at a time.
The same intent, phrased two ways.
| Vague | Specific |
|---|---|
| "What is in the sprint?" | "Search Jira for project = ENG AND sprint in openSprints() and summarise by assignee" |
| "Any bugs about login?" | "Search Jira for project = ENG AND type = Bug AND text ~ \"login\" ordered by created desc, top 20" |
| "Is this documented?" | "Search Confluence in the ENG space for the retry-policy decision, then quote the section" |
| "Update the ticket" | "Move ENG-4521 to In Review and comment with the PR link and what still needs a decision" |
Scoping which tools it may use
Atlassian tools are addressable like any other MCP tool, as mcp__<server>__<tool> using the name you gave the server. That lets you auto-approve reads and keep a prompt in front of anything that changes a ticket.
{
"permissions": {
"allow": [
"mcp__atlassian__get*",
"mcp__atlassian__search*"
],
"ask": [
"mcp__atlassian"
]
}
}
When it will not connect
| Symptom | Cause | Fix |
|---|---|---|
! Needs authentication, forever | OAuth never completed | claude mcp login atlassian |
| Browser opens, then nothing | Redirect could not reach the CLI | Paste the full callback URL at the prompt |
| No browser on the machine | SSH or headless | --no-browser, and ssh -t |
| Connects, but no Jira tools | Wrong permission groups granted | Re-authorise and grant Jira read and write |
| No Service Desk or Bitbucket tools | OAuth does not cover them | Use an API token instead |
| No Compass tools | API token does not cover Compass | Use OAuth instead |
| Sees nothing in a project | Your account cannot see it either | Fix it in Atlassian, not here |
| Fails after a while | Hourly rate limit | Fewer, broader queries |
| Nothing works, self-hosted instance | Cloud only | No remote server exists for you |
claude mcp remove atlassian
claude mcp logout atlassian
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2
claude mcp login atlassian
claude mcp list
Questions people ask
Run claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2, then run /mcp inside a session and complete the browser sign-in. That one server covers Jira, Confluence, Jira Service Management, and Bitbucket.
Atlassian's official remote MCP server for its Cloud products. It exposes Jira, Confluence, Jira Service Management, Bitbucket, and Compass to any MCP client over OAuth 2.1 or an API token, and every action runs with the permissions of the signed-in user.
https://mcp.atlassian.com/v1/mcp/authv2. The plain /v1/mcp endpoint is also supported and is what API-token setups use. The older /v1/sse endpoint still works but uses the deprecated SSE transport.
No. The remote server is Atlassian Cloud only. Self-hosted Data Center and Server deployments need a community server or a thin internal MCP server in front of the REST API, both of which you secure yourself.
OAuth for interactive use: nothing is stored in your config and it respects your existing permissions. API tokens for headless use, and for Jira Service Management and Bitbucket, which OAuth does not cover. Compass is the reverse, OAuth only.
No. The server acts as you, so it inherits exactly your permissions and nothing more. A project invisible to your Atlassian account is invisible to the agent.
Yes, per hour by plan: 500 calls on Free and 1,000 on Standard, with Premium and Enterprise adding 20 per user on top of 1,000 up to a 10,000 ceiling. Sweeping a whole board in a loop is the pattern that hits them.
The OAuth flow has not completed. Run claude mcp login atlassian, or /mcp from inside a session. On a remote machine with no browser, add --no-browser and connect with ssh -t so you can paste the redirect URL back.
Sources
Every figure above was read from these pages on 3 August 2026. Vendors reprice without notice; if you find a stale number, tell us.