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