Error making tool calls to Rovo MCP Server

[Shivam_Saith]

We are using the official Atlassian Rovo MCP Server - 

We have a custom MCP client and when we make a tool call to the Rovo MCP server after successfully authenticating , we see an error when making a tool call from the client. This is after the user sucessfully authenticates as well as provides the necessary authorization including the scopes.

Failed to call tool: {"meta":null,"content":[{"type":"text","text":"{\"error\":true,\"message\":\"We couldn't verify your access. Reconnecting and signing in again may resolve this issue.\"}","annotations":null,"meta":null}],"structuredContent":null,"isError":true}

"message_parsed": {
"connector_id": "cnb-jira-oauth-51fpu9",
"err": "oauth: no refresh token in connector data",
"level": "ERROR",
"msg": "failed to refresh identity",
"request_id": "e04927d5-b537-44e1-ac27-eb43c78a6313",
"source": {
"file": "/usr/local/src/dex/server/refreshhandlers.go",
"function": "github.com/dexidp/dex/server.(*Server).refreshWithConnector",
"line": 344
},
"time": "2026-08-10T19:08:11.183Z",
"user_id": "1f5fd952-1054-4431-ac2e-615d269c32f1"
},

Additionally, we would also like to know where and how we can see all the Rovo MCP Server generated logs and telemetry - currently we are unable to see those. Please help with this ASAP

Thanks!

[James Gamble]

Hola Shivam,

The error you captured points much more specifically to an OAuth refresh problem than to missing Jira permissions or scopes. The key line is “oauth: no refresh token in connector data” followed by “failed to refresh identity.” Since initial authentication and consent succeed, but the first tool call fails when Atlassian tries to refresh the authenticated identity, I’d focus on the OAuth session rather than the tool invocation itself.

There was also a significant change to Rovo MCP authentication earlier this year that’s particularly relevant to custom clients. Atlassian moved Rovo MCP’s Dynamic Client Registration OAuth flow to a new Atlassian Identity authorization server beginning May 27, 2026, and specifically warned custom-client implementations not to cache the OAuth client_id or OAuth discovery metadata from the previous authorization server. Atlassian’s current endpoint for custom MCP clients is https://mcp.atlassian.com/v1/mcp/authv2. I’d clear any cached OAuth/DCR state in the client, including the registered client ID, authorization server metadata, access tokens, and refresh tokens, then reconnect using that endpoint and complete a new authorization flow. Atlassian documents the authentication change in the Rovo MCP changelog here.

I’d also verify that your custom client fully supports the OAuth 2.1 token lifecycle, rather than only completing the initial browser authorization. Atlassian explicitly requires OAuth 2.1 support for custom MCP-compatible clients, and its troubleshooting guidance recommends re-running the complete connection flow when the token refresh or authorization state becomes invalid.

For the logging question, organization admins do have visibility into MCP activity, but not the complete server-side debug logs shown in your error. Go to Atlassian Administration > Insights > Audit log and filter for Rovo MCP User Actions or search for MCP. Atlassian records tool invocations there, including the tool, action, and user. Their documentation is here.

I don’t see a documented admin interface that exposes Rovo MCP’s internal server logs or telemetry, such as the Dex refresh-handler entries you’ve captured. For those, I’d open an Atlassian Support case and provide the exact timestamp, user ID, connector ID, request ID e04927d5-b537-44e1-ac27-eb43c78a6313, the MCP endpoint your client is using, and confirmation that a clean authorization against /authv2 reproduces the problem. That request ID should give Atlassian something concrete to correlate against their backend telemetry.

Thanks,

James

[Syed_Muntaser]

Thanks James, I'm working with Shivam on this issue; one thing we noticed was that the refresh token issue persists after we added "offline_access" to scope on our MCP client side. Could we verify if adding 'offline_access' to scope helps?

Thanks, 
Muntaser

[James Gamble]

Hola Muntaser,

I don’t see offline_access listed in Atlassian’s published Rovo MCP guidance as a required scope for custom clients, so adding it isn’t expected to fix the issue on its own.

The important part is that you’re still getting “oauth: no refresh token in connector data” even after requesting offline_access. That suggests the problem is with the refresh token not being issued or retained correctly, rather than with that scope simply being absent.

At this point, I’d verify that your client is following Atlassian’s documented OAuth 2.1 flow exactly and, if the same error persists, raise it with Atlassian Support so they can determine whether the refresh token is being omitted during issuance or lost when the connector state is stored.

Thanks,

James

[Shivam_Saith]

Thanks James - quick clarification - should we use https://mcp.atlassian.com/v1/mcp/authv2 as the Authorization URL that our custom MCP client needs or should that be

https://auth.atlassian.com/authorize

I've seen some conflicting information online around this - hence the confusion

Best,
Shivam

[James Gamble]

Hola Shivam,

The two URLs serve different purposes.

For your custom MCP client, keep https://mcp.atlassian.com/v1/mcp/authv2 configured as the MCP server endpoint.

For the OAuth authorization endpoint, I wouldn’t hard-code https://auth.atlassian.com/authorize. Instead, have the client follow Atlassian’s OAuth discovery flow. For the authv2 MCP endpoint, the protected-resource metadata is available here.

That metadata should lead the client to the current authorization server and its authorization/token endpoints. Atlassian’s current changelog documents the discovery behavior here.

Given the refresh-token behavior you’re troubleshooting, I’d check specifically whether your custom client is performing that discovery rather than using a statically configured authorization URL.

Thanks,

James

[Tomislav Tobijas]

I'm going to move this to Rovo Q&A forum group. Hopefully someone will be able to chime in on this. 👀

I'm currently OOO and 'away from laptop' (whatever that means 🫠), but if no one jumps in, I can take a look at this next week.

Cheers,
Tobi