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

[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