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

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

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 🤠 

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."}

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 , 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:

1. 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.
2. Check the Atlassian status page for Rovo and subscribe; a regression this wide usually gets a status entry once enough reports land.
3. 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.

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.

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?