Announcing authentication via API token for Atlassian Rovo MCP Server

[#1]

Atlassian's Model Context Protocol (MCP) makes it easier to bring Atlassian data and actions into AI tools through a consistent, server-side integration model. Until now, Atlassian Rovo MCP has supported only OAuth as its primary authentication mechanism, which means:

• An interactive browser-based consent flow is required, and
• MCP servers primarily run in user-interactive contexts, for example, where a human can click through OAuth prompts).

We're excited to share that authentication via API token access for Atlassian MCP is now supported — a new way to connect to MCP without an interactive consent screen, designed specifically for machine‑to‑machine and automated use cases.

What is authentication via API token access?

Authentication via API token access lets MCP clients authenticate without an interactive user flow in a browser. Instead of redirecting to a consent page, your MCP client authenticates using personal API tokens via Basic Auth, and service account–style credentials for non-human workloads.

In practice, this enables you to:

• Run MCP clients from CI/CD pipelines, scheduled jobs, or backend services
• Use MCP in non‑interactive environments (servers, cron jobs, agents, platform workers)
• Avoid browser‑based redirects while still leveraging Atlassian's existing authentication and authorization model

Authentication via API token access is an additional authentication option alongside OAuth and does not replace OAuth. OAuth remains the best fit for end‑user, interactive scenarios.

Why this matters

Authentication via API token access unlocks new ways to use Atlassian MCP:

• Automate workflows end-to-end: Run MCP tools on a schedule or in response to events, such as sync/triage Jira issues and update Confluence pages.
• Integrate with your infrastructure: Call MCP from backend services, internal platforms, and agents/workers without a logged-in browser user.
• Use MCP where browsers don't exist: Containers, servers, and cron jobs can now authenticate directly while respecting token permissions.

Authentication options for Atlassian MCP

With this new authentication method, you'll have two ways to authenticate with Atlassian MCP:

1. OAuth 2.1 bearer tokens (existing and interactive)

This is the best option for end-user driven scenarios where interactive consent is acceptable. This method uses the standard OAuth 2.1 flow, requires a browser-based consent screen, and is ideal when a human user can approve access.

2. Atlassian API token with Basic Auth (new, non-interactive, and optional)

This is the preferred option for user-scoped automation from non-interactive environments. This method uses a personal API token created by the user and sent via HTTP Basic Auth in the Authorization header (Basic base64(email:api_token)). Tools run with the same permissions as the token owner.

How it works (high-level)

Your MCP client connects to the Atlassian MCP server at:

https://mcp.atlassian.com/v1/mcp

The client includes an Authorization header using Basic Auth with your email and API token:

Authorization: Basic BASE64_ENCODED_EMAIL_AND_TOKEN

MCP tools execute with the permissions associated with that token, enabling access to Jira, Confluence, and other Atlassian apps as permitted.

This design lets us support non‑interactive clients while staying aligned with how Atlassian tokens are created, managed, and revoked today.

In our official documentation, we'll show how the MCP server, tokens, and Atlassian cloud services interact in more detail.

Getting started (preview)

Here's a quick look at how you'll configure the new method in your MCP client once it's available.

1. Create a personal API token

You'll generate a personal API token from your Atlassian account security settings:

[Please create API tokens with scopes]

• Go to: https://id.atlassian.com/manage-profile/security/api-tokens?autofillToken&expiryDays=max&appId=mcp&selectedScopes=all
• Create a new token for your MCP client.
• If necessary, select the scopes you want your API token to have.
• Store it securely (for example, in your CI/CD secret store or vault).

2. Base64‑encode your email and API token

Create a base64‑encoded string from your email and API token in the format email:api_token:

# Format: base64(email:api_token)
echo -n "your.email@example.com:YOUR_API_TOKEN_HERE" | base64

Copy the output — this is what you'll use in your MCP configuration.

3. Configure your MCP client

Here's an example mcp.json configuration using Basic Auth:

{
  "mcpServers": {
    "atlassian-rovo-mcp": {
      "url": "https://mcp.atlassian.com/v1/mcp",
      "headers": {
        "Authorization": "Basic BASE64_ENCODED_EMAIL_AND_TOKEN"
      }
    }
  }
}

Or

"atlassian-rovo-mcp": {
  "command": "npx",
  "args": [
    "mcp-remote@latest",
    "https://mcp.atlassian.com/v1/mcp",
    "--header",
    "Authorization: Basic BASE64_ENCODED_EMAIL_AND_TOKEN"
  ]
}

Replace BASE64_ENCODED_EMAIL_AND_TOKEN with the value you generated in the previous step.

Admin settings and controls

This capability is off by default.

Because OAuth allowlists do not apply to agents using API tokens, an Org admin must explicitly enable this feature in order for api tokens to be honored.

Troubleshooting

Agent only discovers two tools

If your agent is only discovering two tools, the most likely cause is an incorrectly encoded token

Your api token scopes are not added properly in case you didn't use Rovo MCP API Token, please review the scopes here https://support.atlassian.com/atlassian-rovo-mcp-server/docs/supported-tools/

Update latest IDE and Desktop

• Please ensure to use https://mcp.atlassian.com/v1/mcp
• Please ensure to update your IDE to latests.
• Please ensure to use mcp-remote@latest

Auth Issues

If you face any authentication issues with OAuth, please use API tokens to resolve them. 

Current limitations and roadmap

Initial limitations

No domain allowlist validation via redirect URIs: Because there is no redirect URI, domain allowlist checks tied to redirects are bypassed; IP allowlist enforcement is enabled as a separate control and is supported for all authentication methods.

On the roadmap

We're exploring support for product and cloudId filters so you can control which products and sites MCP tools can access when authentication via API token access is used.

Learn more and share feedback

• Watch the Atlassian Community post for updates and timelines.
• Identify use cases for authentication via API token (CI/CD, agents, internal platforms) and share feedback in the comments.
• Your feedback will directly shape how we evolve this new authentication method for Atlassian Rovo MCP.

[Ibby]

Rovo MCP Scoped Token

Org Admin Setting to be enabled

[bondansebastian]

Hi, I'm having trouble connecting to the MCP server, I've make sure to follow every steps mentioned in the guide.

1. Enabling Org admin setting 
2. Setting up the API token
   

Are there any missing steps? 

Thank you

[Ibby]

Hey @bondansebastian 

Did you create a new Rovo MCP Token? when 2 tools are showing it either means token encoding issue or it's not using Rovo MCP scoped Token.

[bondansebastian]

Ah, I used a previously created token which is probably is not a Rovo MCP token. It works now! Thanks for the help.

[Ahmed Salman]

@Ibby  [re - rovo mcp token based auth] The app is activated and functioning for users. However, when attempting to create a scoped token for service accounts, "Rovo MCP" does not appear in the list of available apps.  

[Ibby]

Hey @Ahmed Salman 

For Service Account, you would need to select the required scopes manually for now.

https://support.atlassian.com/atlassian-rovo-mcp-server/docs/supported-tools/

[Michał Maciaszek]

Did something change since yesterday? I am creating OpenAI agent, that would connect to Rovo MCP (below basic "demo"). I created API token, based64 it according to instruction.

But since yesterday morning I am getting (openai.APIStatusError: Error code: 424 - {'error': {'message': "Error retrieving tool list from MCP server: 'dmcp'. JSON-RPC 2.0 error code: -32601", 'type': 'external_connector_error', 'param': 'tools', 'code': 'mcp_protocol_error'}}).

Could you give me a hint, if I am doing something wrong, or did something change?

[Ibby]

Hi @Michał Maciaszek 

What type of token did you create, is it a scoped token? I did a quick test and it's working for me and few team members too.

Can you share your pip requirement too? Also non of the allowed tools in your script can get a Jira Issue.

[Michał Maciaszek]

Edit:
I managed to fix it, I should have used:

"headers": {"authorization": "Basic <encoded stuff>"}, instead of just "authorization". But I could swear, that two days ago I didn't have to do this.

Regarding a token, I create it according to instructions here: https://support.atlassian.com/atlassian-rovo-mcp-server/docs/getting-started-with-the-atlassian-remote-mcp-server/ (autogenerated with this link: https://id.atlassian.com/manage-profile/security/api-tokens?autofillToken&expiryDays=max&appId=mcp&selectedScopes=all); so it should have all scopes.

I use openai==2.25.0 (but it didn't work for 2.0.1 version too).

When allowed_tools are removed it doesn't work either.

I have a feeling, that I'm crazy, because it worked on wednesday evening, but stopped working on thursday morning :D

[Steven Drury]

Hey @Dilip Venkatesh

This workaround is only really viable for individuals as we can't specify headers for the official connectors.

What we really need is one of the following: 

1. OAuth to be moved from the Site level to the Org level - I realise this is very unlikely to be implemented
2. Modification to the url path for `https://mcp.atlassian.com/v1/mcp` so we can specify the target site for that connection. This allows us to add multiple connectors at the org level in Claude or ChatGPT. For example: https://mcp.atlassian.com/v1/mcp&site=site1.atlassian.net. We then use a custom connector for each of our sites rather than the official Atlassian connector. 

Multi-site has been an issue from day 1 and it's causing so much pain for enterprises with work in multiple sites. 

[Juan Pablo Gavagnin]

Hey, this is a great feature, we were waiting for something like this, thank you!

Having said that, I am having a particular issue. I am connecting to the Rovo MCP server through Python (httpx + mcp lib). I am using:

- API Token with read only access scopes + search (personal for testing, we'll migrate to SA later).

- URL: https://mcp.atlassian.com/v1/mcp 

Everything goes smoothly, I can list tools, call a lot of tools. The only tool I am having trouble with is the "search" tool, it's returning this error:

{"error":true,"message":"Search service is temporarily unavailable. Please try again in a few moments. Details: {\\n \\"error\\": \\"RovoService service error\\"\\n}"}

I've been trying for a long time, so this doesn't look like a transient error (regarding the specific error message returned). I am sending the 2 required parameters query and cloudId (either cloud id or url, tested with both). I might be doing something wrong, or this is not a transient error, or the actual error is being shadowed for some reason.

Thank you!

[Jatin K Malik]

Hello @Juan Pablo Gavagnin 

We tried investigating the error that you shared but even with replicating your scope we did not get an error and we were not able to reproduce this issue.

Would you mind filing a support ticket so that we can get some logs and get some more information about how you configure your scope? That will allow us to help solve this issue in a much better way for you.

File a ticket here like this: https://support.atlassian.com/contact