Rovo MCP tools returning "We are having trouble completing this action" after successful OAuth

[Jerome Grunnagle _Trey_]

I'm using the Atlassian remote MCP server (`https://mcp.atlassian.com/v1/mcp`) and running into a consistent error after successfully completing the OAuth flow.

**Setup**

I created an OAuth 2.0 (3LO) app in the Atlassian developer console, configured a redirect URI, and requested the following scopes:

- `read:me`

- `read:jira-user`

- `read:jira-work`

- `read:confluence-content.all`

- `read:confluence-space.summary`

- `read:confluence-user`

- `search:confluence`

- `offline_access`

The authorization code flow completes successfully and includes PKCE (`code_challenge`/`code_verifier` with S256) — so the flow is OAuth 2.1-compliant on that front. I receive an access token and can confirm it is valid by calling `https://api.atlassian.com/me`.

I've also allowlisted my redirect domain in **Atlassian Administration → Rovo MCP server settings**.

**The problem**

When I connect to `https://mcp.atlassian.com/v1/mcp` and pass the access token as a Bearer token in the `Authorization` header, the connection is established and tools are listed successfully. However, calling any tool returns:

```json

{"error":true,"message":"We are having trouble completing this action. Please try again shortly."}

```

This happens for every tool — including simple read operations. The error is immediate, consistent across retries, and occurs with both fresh and refreshed tokens.

**What I've ruled out**

- Token validity — confirmed via `/me` API call

- Domain allowlisting — configured in Rovo MCP admin settings

- Scope mismatch — scopes on the token match what is configured in the developer console

- PKCE — the authorization flow uses S256 code_challenge/code_verifier, satisfying the OAuth 2.1 requirement

**Hypothesis: pre-registered app vs. Dynamic Client Registration**

The Atlassian MCP documentation notes that if an MCP client supports Dynamic Client Registration (DCR), no manual app registration is required — the server handles it automatically. I am not using DCR; I am using a pre-registered app with a client ID and secret from the developer console.

My question is whether this distinction matters at the MCP tool-call layer. Specifically: could tokens issued to a pre-registered OAuth app be treated differently by the Rovo MCP server backend compared to tokens issued via DCR — for example, missing an internal entitlement, a different audience claim, or a different token binding — in a way that would cause tool calls to fail even though the token passes authentication?

**Questions**

1. Is DCR the only supported registration path for the Rovo MCP server, or are pre-registered apps fully supported?

2. Is there a Rovo-specific license or entitlement required on the Atlassian Cloud site beyond having access to Jira/Confluence? Could the error indicate the connected site doesn't have Rovo enabled?

3. Is there any way to retrieve a more detailed error — a request ID, error code, or diagnostic log — to identify the root cause?

Any guidance would be appreciated.

[Arkadiusz Wroblewski]

Hello @Jerome Grunnagle _Trey_ 

I wouldn’t jump to licensing as the culprit just yet.

Since your OAuth is working and you can actually see the tools, the "handshake" itself is fine. That specific error message "We are having trouble completing this action" is exactly what Atlassian points to when there’s a transient snag during the permission check right as the tool tries to fire.

Instead of looking at the bill, I'd first double-check the Rovo MCP server permissions in your admin console to ensure "Read"  and "Search"  are fully enabled, as that’s the main gatekeeper now. You should also keep an eye on your IP allowlists; if your organization is locked down, it might be silently blocking the MCP calls. Scopes are another tricky spot because they’re getting more granular lately for instance, you might specifically need search:rovo:mcp or the newer read:page:confluence scopes to actually execute the calls.

If you check your Audit logs and don't see any obvious "access denied" events, this is likely one of those backend gremlins that Atlassian needs to squash. Since the beta tools are currently free to use for Cloud sites, this looks less like a missing subscription and more like a systemic permission-check failure that needs a support ticket to resolve.

Have you had a chance to look at the Org Audit logs to see if the tool invocations are even registering there?

[Jerome Grunnagle _Trey_]

There are no events in the org's audit logs. I've enabled these permissions in the admin panel: