nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Atlassian Rovo MCP fails from ChatGPT with “We are having trouble completing this action” on Free pl

Nicolás Diego Apolonia

Hi,

I’m having a persistent issue using the official Atlassian Rovo MCP Server from ChatGPT.

My environment is:

Atlassian Cloud
Jira Cloud
Free plan
Official ChatGPT plugin: Atlassian Rovo — Jira, Confluence, Loom, & more
Authentication: OAuth 2.1

The OAuth authorization completes successfully and the Atlassian tools are available inside ChatGPT. However, even the most basic MCP operations fail immediately with:

“We are having trouble completing this action. Please try again shortly.”

For example, ChatGPT cannot successfully execute:

getAccessibleAtlassianResources
atlassianUserInfo

The error therefore occurs before attempting to access a particular Jira issue.

Troubleshooting already performed

I have already:

Removed the existing Atlassian credentials from ChatGPT.
Removed the previous Atlassian plugin.
Installed the official Atlassian Rovo — Jira, Confluence, Loom, & more integration again.
Completed a completely new OAuth authorization.
Confirmed Allow Atlassian supported domains is enabled.
Confirmed all Rovo MCP Server permissions are allowed:
- Read: 13/13 allowed
- Write: 13/13 allowed
- Search: 4/4 allowed
- Delete: 1/1 allowed
- Manage: 1/1 allowed
Confirmed OAuth 2.1 is being used, which Atlassian shows as the default authentication method.
API-token authentication is disabled because this is an interactive OAuth connection from ChatGPT.
Enterprise-managed authentication is also disabled.

Reconnecting and reinstalling the integration does not change the result.

Free plan / entitlement question

I initially suspected that this could be caused by using the Atlassian Free plan.

However, Atlassian’s current Rovo MCP documentation states that all Atlassian Cloud customers have access to the Atlassian Rovo MCP Server, with the following site-level limit for Free:

Free: 500 calls per hour

Therefore, unless there is an undocumented entitlement requirement, I don’t believe upgrading from Free to Standard should be required just to perform basic Jira MCP operations.

Could someone from Atlassian confirm this?

Error documented by Atlassian

Atlassian’s Rovo MCP permission documentation lists this exact error:

“We are having trouble completing this action. Please try again shortly.”

and describes it as:

“A transient backend error occurred during the permission check.”

The suggested resolution is to retry, and if the issue persists, contact Atlassian Support.

Since Free-plan users cannot open a normal technical support request and are directed to Community, I’m posting the issue here.

Similar reports

I have also found several Community reports from 2026 where OAuth and tool discovery succeed but MCP tool execution returns the same generic error.

There is even another report involving an Atlassian Free Plan where OAuth, Cloud ID, tool discovery, domain configuration, and Rovo permissions had all been verified, but MCP execution still failed with the same message.

Questions

Is the Free Jira Cloud plan definitely entitled to use basic Rovo MCP Jira read/write operations from ChatGPT?
What should I do from my side to get this working?

Thanks.

References

Official Rovo MCP — access and plan limits.
Atlassian Rovo MCP — official product page
Rovo MCP Server permission configuration.
Configure Atlassian Rovo MCP server permissions
Very similar case involving the Free plan.
Community: Remote MCP tools fail despite successful OAuth
Case where atlassianUserInfo fails with the exact same error.
Community: Rovo MCP server issue

Accepted answers

Nicolás Diego Apolonia

Final update / Resolution

Atlassian has now created an official public bug to track this issue:

ECO-1782 – MCP v2: All tool calls fail with "We are having trouble completing this action. Please try again shortly."

The issue is currently marked as Unresolved / Needs Triage, and Atlassian confirms that there is currently no known workaround.

Since the issue is now officially being tracked by Atlassian under ECO-1782, future updates and progress on the issue can be followed directly through the official bug report.

Thanks to everyone who helped investigate this, especially for the explanations and troubleshooting suggestions along the way.

All comments

Arkadiusz Wroblewski

Hello @Nicolás Diego Apolonia

Check Atlassian Administration → Insights → Audit log, filter for MCP / Rovo MCP User Actions.

MCP invocation logging is available on all tiers. If the failed atlassianUserInfo call is recorded, note the timestamp and tool name.

As you're on Free and can't raise a standard technical support request, I've asked Atlassian for help on this Community question.

This needs Atlassian investigation; their documentation recommends contacting Support if this backend permission error persists.

Best,

Arek 🤠

Tomislav Tobijas

To add on this @Nicolás Diego Apolonia ...

Is the Free Jira Cloud plan definitely entitled to use basic Rovo MCP Jira read/write operations from ChatGPT?

Yes. I'm using it daily basis on 2 instances/sites with Free plans and it works seamlessly. Also, there are no plans (as far as I know) to put this behind some kind of paywall, so you should be good.

What should I do from my side to get this working?

I'm guessing you've tried the new SDK app/plugin. What you can potentially try is the old connector to see how that goes: Atlassian Rovo | Read/write Jira & Confluence
I don't think this version support Codex, but for basic operations, including creating content, should be all good.

Even though it shouldn't matter, question: Are you using web or desktop version of ChatGPT? You could try disabling browser extensions and potentially just try to use different network to re-connect/do the authentication. 👀

If no one from Atlassian gets back to you here, what you can do is to start free trial of Standard or Premium, raise a support ticket, and once you resolve this, simply switch back to free plan. This is usually the fastest way to resolve any issues you might have 🎟️

Cheers,
Tobi

Nicolás Diego Apolonia

I was able to complete an external test using Postman against the new Rovo MCP v2 endpoint.

After enabling API token authentication for the organization and using the required Jira agent-interface scopes, the MCP flow works correctly:

1. initialize succeeds
2. the MCP session is established successfully
3. tool calls reach Atlassian
4. Jira can be accessed
5. getJiraIssue successfully retrieves my Jira tickets

I then immediately retried getAccessibleAtlassianResources from ChatGPT using the Atlassian Rovo connector, and it still returns:

"We are having trouble completing this action. Please try again shortly."

This appears to confirm that the Atlassian Rovo MCP server, the Jira site, my Jira permissions, and the MCP v2 API itself are working correctly when accessed externally.

The issue therefore seems to be specific to the ChatGPT to Atlassian Rovo connector or authentication path.

Another relevant observation is that the failed ChatGPT calls do not seem to appear in the Atlassian Rovo MCP Audit Log, while successful MCP and Jira calls do.

Considering that Rovo MCP v2 was released on September 8 and that third-party connectors are currently being updated, could this be related to the ChatGPT connector migration to MCP v2, or possibly stale OAuth or client metadata?

Nicolás Diego Apolonia

Thanks, Arek. I really appreciate the explanation and also your help escalating this to Atlassian.

The Audit Log details were especially useful and helped me narrow down the issue further. I’ll keep the thread updated with any additional findings from my tests.

Thanks again for your help!

Nicolás Diego Apolonia

Thanks, Tobi. I really appreciate the detailed explanation and the confirmation that the Free plan should work with Rovo MCP.

I’ll keep testing both connector options and the authentication flow. I also tried the old connector, as you suggested, to compare the behavior, but it fails as well.

Thanks as well for the additional troubleshooting ideas around the desktop/web app, extensions, and reconnecting from a different network. Very helpful.

Arkadiusz Wroblewski

Nothing to thank, we are here to help each other.

Logs are the best thing ever invented 🤣 They always help, at least in knowing where to start looking for a problem to troubleshoot.

ben_np9yab

Hi Nicolás,

It's not you, it's Jira.

Stopped working for me in Codex, Claude, OpenCode and Cursor in the exact same way at exactly the same time as you.

I had made no changes, it just stopped working in all clients in the same way you experience the issues. I was wondering if Jira had quotas on free tier - they do, but I'd be way under them.

I've re-authenticated all clients, no improvement. I haven't changed any permissions.

It's a Jira issue.

Looks like we just have to wait for it to be fixed.

Cheers,
Ben

• Called atlassian.getAccessibleAtlassianResources({})
└ {"error": true, "message": "We are having trouble completing this action. Please try again shortly."}

Dávid Sass-Kovács

Same issue here from Claude Code, starting 9 Sep, identical error on atlassianUserInfo and getAccessibleAtlassianResources.

Setup: two separate Cloud sites (one Jira, one Confluence), each registered as its own MCP entry against https://mcp.atlassian.com/v2/mcp, OAuth 2.1 via DCR.

What we've ruled out:

- Rovo MCP admin config is clean: Read 13/13, Write 13/13, Search 4/4 allowed, "Allow Atlassian supported domains" ON.
- Full disconnect + fresh OAuth ~8 times. The handshake always succeeds and tool discovery returns the full tool list, only tool execution fails.
- The endpoint itself is healthy, an unauthenticated POST to /v2/mcp returns 401 {"error":"invalid_token"} in ~0.1s, and /.well-known/oauth-protected-resource/v2/mcp returns 200.
- Both status pages stayed green the whole time.

Corroborating Nicolás' Postman result: our Bitbucket entry pointing at /v1/bitbucket/mcp with an API token (Basic auth) has worked continuously throughout, while every OAuth 2.1 call to /v2/mcp fails. So the API-token path looks fine and the OAuth 2.1 path on v2 is what's broken, and it isn't ChatGPT-specific, since Claude Code behaves identically.

Sami Shaik

@Nicolás Diego Apolonia , with @Dávid Sass-Kovács and @ben reports the thread now has enough evidence to stop diagnosing your setup and name the pattern:

OAuth 2.1 to /v2/mcp fails; API token to the v1 and Bitbucket paths keeps working, on the same accounts, at the same time.
Every client behaves the same: ChatGPT, Claude Code, Codex, Cursor, OpenCode. Not connector-specific.
The handshake succeeds and tool discovery returns the full list; only tool execution fails, starting with the two cheapest read calls.
Onset is 9 September, with "Allow Atlassian supported domains" on in at least one org, so the domain allowlist is not the gate, and the permission counts everyone is quoting are the default open posture, so permissions are not the gate either.
Rovo MCP v2 went GA on 8 September per the developer changelog.

That combination (one auth path broken across all clients, the other path fine, starting the day after a GA) is what a server-side regression on the OAuth 2.1 token validation for v2 looks like, not a misconfiguration on your side. @Tomislav Tobijas and @Arkadiusz Wroblewski were right to get entitlement and logs out of the way first; the logs are now what turns this into a report.

What I would do today, in this order:

File it on jira.atlassian.com, which is open to Free-plan accounts, so the "cannot open a Support ticket" wall does not apply. One report with the four bullets above, the exact error text, the timestamp of a failed call, and the client list carries far more weight than four separate threads. Before filing, search that tracker for an existing v2 MCP issue from 9 September; if one exists, vote and comment rather than duplicate.
Check the Atlassian status page for Rovo and subscribe; a regression this wide usually gets a status entry once enough reports land.
Keep the working path working: do not toggle the API token switch off to "reset" anything. It is a separate door and it is the one that still opens.

For anyone arriving later: if OAuth works from Postman-style tests but not from your client, that is a domain-list question. If OAuth fails everywhere and tokens work, as here, it is not.

Nicolás Diego Apolonia

I have another update after doing a more complete test directly against the Rovo MCP v2 endpoint with Postman.

This time I was able to complete the actual OAuth 2.1 flow independently of ChatGPT:

Registered a client successfully using Dynamic Client Registration (DCR).
Used the Authorization Code flow with PKCE (S256) and PAR.
Included the required scopes and offline_access.
Atlassian authentication and consent completed successfully.
Received the authorization code and successfully exchanged it for an access token.
initialize against https://mcp.atlassian.com/v2/mcp succeeds and the MCP session is established.
I can proceed normally through the MCP protocol up to actual tool execution.

However, calling atlassianUserInfo directly from Postman then returns:

{
"result": {
"content": [
{
"type": "text",
"text": "{\"error\":true,\"message\":\"We are having trouble completing this action. Please try again shortly.\"}"
}
],
"isError": true
},
"jsonrpc": "2.0",
"id": 3
}

I also tested getJiraIssue through the same OAuth-authenticated MCP session, and it returns the same generic error.

This gives us a useful A/B comparison from the same external client:

API-token authentication: MCP session works and getJiraIssue successfully retrieves Jira issues.

OAuth 2.1 authentication: DCR, PAR, PKCE, authorization, token exchange and MCP initialization all succeed, but actual Atlassian tool execution fails with “We are having trouble completing this action. Please try again shortly.”

Therefore, I can now reproduce the problem completely outside ChatGPT.

This seems to rule out the ChatGPT connector itself as the root cause and points much more specifically to the OAuth 2.1 execution/authorization path on Rovo MCP v2. The OAuth token is accepted well enough to establish the MCP session, but something appears to fail when the server tries to execute an Atlassian tool using that authenticated user context.

This also seems consistent with the other reports in this thread where different MCP clients started failing at the same time while non-OAuth/API-token paths continued to work.

Hopefully this additional direct Postman reproduction helps narrow down where the regression is occurring.

Nicolás Diego Apolonia

Final update / Resolution

Atlassian has now created an official public bug to track this issue:

Since the issue is now officially being tracked by Atlassian under ECO-1782, future updates and progress on the issue can be followed directly through the official bug report.

Thanks to everyone who helped investigate this, especially for the explanations and troubleshooting suggestions along the way.

Tomislav Tobijas

@Nicolás Diego Apolonia not an ideal outcome, but thanks for sharing the ECO link! I've dropped my vote.

Hope it will get resolved soon 🤞

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

rovo-atlassian-intelligence