Hi,
I’m integrating Atlassian Rovo MCP from a custom agent (not Cursor/Claude + mcp-remote). The MCP session authenticates with a short-lived OAuth 2.0 (3LO) access token sent as Authorization: Bearer <token> to the Streamable HTTP endpoint.
Environment
-
MCP endpoint:
https://mcp.atlassian.com/v1/mcp(env override possible viaATLASSIAN_MCP_URL). -
Transport: Streamable HTTP / SSE-style MCP client (Google ADK
McpToolset+StreamableHTTPConnectionParams), not stdio /npx. -
Auth: OAuth 2.0 (3LO) authorization code flow; access token issued for audience
api.atlassian.com. Confluence-related scopes enabled on the OAuth app (classic scopes such as read/write Confluence content, space summary, search, user, plusread:me/read:account, andoffline_accesswhere applicable). -
Cloud: Confluence on Atlassian Cloud (site URL of the form
https://<site>.atlassian.net).
What works / what doesn’t
-
I have obtained a fresh access token (recent authorization, token not expired at time of call).
-
When the agent invokes the MCP tool
getAccessibleAtlassianResources, the tool response comes back as an error with no actionable detail.
Actual response (tool result)
Invoking getAccessibleAtlassianResources returns structured content along these lines (identifiers from my client session):
-
Tool name:
getAccessibleAtlassianResources -
Response text (JSON):
{"error":true,"message":"We are having trouble completing this action. Please try again shortly."} -
isError:true
I’m not seeing a distinct HTTP status from my side beyond the MCP tool framing—the failure is surfaced as the tool’s text payload above.
Expected behavior
getAccessibleAtlassianResourcesshould return the list of Atlassian Cloud resources accessible to the authenticated user (or a specific, documented error—e.g. scope, entitlement, or auth—so we can correct OAuth app configuration).
What I’ve already checked
-
New token after re-consent; same outcome on repeated tries (not only “stale session”).
-
Same bearer token will be used for other Rovo MCP tools (e.g. Confluence search / spaces / user info). (Please confirm: if those succeed but only this tool fails, is that a known limitation or service issue?)
-
Org/product: I’m assuming Rovo MCP is permitted for our tenant; if there is a required admin toggle or sku specifically for “accessible resources” vs basic Confluence MCP tools, please point me to the exact doc.
Ask for Atlassian
-
Is
getAccessibleAtlassianResourcessupported and expected to work overhttps://mcp.atlassian.com/v1/mcpwith Streamable HTTP the same way as the SSE path documented for desktop clients? -
Are there additional OAuth scopes or entitlements required only for this tool (beyond normal Confluence read/write/search)?
-
Is the message “We are having trouble completing this action…” a known transient backend error for this tool, or should we treat it as misconfiguration on our side? What logs or correlation IDs can we collect on our side to help you trace (if any)?
-
If this is a known issue, is there a public tracker or workaround (e.g. use
atlassianUserInfo+ explicit site URL instead of resource discovery)?