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

I hit this exact issue and finally root-caused it. Short version: your OAuth setup is correct — Atlassian's own discovery metadata is misleading you.

The Rovo MCP Server's RFC 9728 protected-resource-metadata (https://mcp.atlassian.com/.well-known/oauth-protected-resource/v1/mcp/authv2) advertises authorization_servers: ["https://auth.atlassian.com/<your-tenant-id>"] — the classic OAuth 2.0 (3LO) Auth0-backed identity system. Any spec-compliant client (including a properly pre-registered 3LO app) follows that pointer and gets back completely valid tokens from that server — good enough for direct Jira/Confluence REST calls, which is why token validation via /me succeeds.

But the actual tool-execution gateway behind mcp.atlassian.com doesn't accept those tokens. It only trusts tokens issued by a different, undocumented authorization server: cf.mcp.atlassian.com. That's not referenced anywhere in the resource's own published metadata — the only way to find it is a direct, non-standard GET to:

curl -s https://mcp.atlassian.com/.well-known/oauth-authorization-server

which returns:
{"issuer":"https://cf.mcp.atlassian.com","authorization_endpoint":"https://mcp.atlassian.com/v1/authorize","token_endpoint":"https://cf.mcp.atlassian.com/v1/token","registration_endpoint":"https://cf.mcp.atlassian.com/v1/register", ...}

If your OAuth client registers and authenticates against that auth/token/registration triplet instead of auth.atlassian.com, the exact same tool calls that were failing start returning real data. Confirmed working end-to-end (searchJiraIssuesUsingJql returning actual results) as of today.

so to summarize you shoudl use:
MCP server URL: https://mcp.atlassian.com/v1/mcp/authv2
Authorize URL: https://mcp.atlassian.com/v1/authorize
Token URL: https://cf.mcp.atlassian.com/v1/token
Registration endpoint: https://cf.mcp.atlassian.com/v1/register

Welcome to the community @Jerome Grunnagle _Trey_ and @Ivan Rener

@Ben Johnson based on current Atlassian documentation, pre-registered OAuth 2.0 apps are supported; DCR is recommended but not required. Since the MCP server accepts the token and returns the tool list, this doesn't appear to be a licensing issue. Atlassian also doesn't currently expose detailed MCP execution logs or request IDs. With multiple users reporting the same behavior, this looks more like a platform-side MCP issue than a configuration problem. I'd recommend reaching out to support directly.

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?