Subject: Custom OAuth 2.0 (3LO) app passes Remote MCP handshake but every real tool execution fails (matches ROVO-870 pattern)

Rovo
1

Environment

  • Product: Atlassian Rovo MCP Server (https://mcp.atlassian.com/v1/mcp/authv2)
  • Client: custom, statically registered “OAuth 2.0 (3LO)” app in the Developer Console (client_id Xq2pvfTxz56XtrDktVAwSzAlG35dj3Mc), not Dynamic Client Registration (DCR)
  • Org-level Rovo MCP server settings verified: Domain settings correctly allowlisted; Permissions → Read 13/13, Write 13/13, Search 4/4 — all fully allowed

What works

  • Classic OAuth 2.0 (3LO) authorization-code flow against auth.atlassian.com completes successfully (audience=api.atlassian.com)
  • MCP JSON-RPC initialize → HTTP 200
  • MCP JSON-RPC tools/list → HTTP 200, full tool catalog returned

What fails

  • Every tools/call against a real tool (e.g. getAccessibleAtlassianResources, search, atlassianUserInfo) returns HTTP 200 at the transport level, but the JSON-RPC/tool-result content is an error — variously surfaced as “Please try again shortly”, “We are having trouble completing this action”, or an empty/no-result payload. This is 100% reproducible across multiple sessions and multiple distinct tools, not transient.

What we’ve ruled out

  • Org admin Domain settings (already correctly configured)
  • Org admin Rovo MCP server Permissions (Read/Write/Search all fully allowed)
  • Our own client-side tool allowlist (confirmed the calls do reach the relay and are forwarded)

Suspected cause
Community reports (e.g. forum thread on Atlassian Remote MCP tools fail during execution despite successful OAuth and tool discovery, referencing internal ticket ROVO-870) describe the identical pattern with a statically registered Developer Console OAuth app, concluding that Remote MCP tool execution currently requires a DCR-issued client, not a static one — even though the static client is accepted for the OAuth flow and MCP handshake itself.

Ask
Can you confirm whether static (non-DCR) OAuth 2.0 (3LO) apps are supported for Remote MCP tool execution today? If not, is there a documented workaround or timeline? If they should be supported, what differs about our setup — happy to provide additional trace IDs/timestamps on request (e.g. 2026-08-28T10:25:20Z–10:25:48Z, cloudId available on request).