The GitHub MCP Registry entry for the Atlassian Rovo MCP Server advertises a stale endpoint. The remotes block points to the legacy /v1/mcp path, but Atlassian's current getting-started guidance recommends /v1/mcp/authv2. For organizations whose policy forces MCP clients to consume server definitions directly from the GitHub MCP Registry (no manual URL overrides), this drift causes the OAuth 2.1 flow to fail, forcing a fallback to API-token authentication.
The discrepancy
GitHub MCP Registry — com.atlassian/atlassian-mcp-server, version 1.1.1 (is_latest: true):
Source: https://api.mcp.github.com/v0/servers/search?q=atlassian
Atlassian's official getting-started doc (current banner at top of page):
After 30th June 2026, usage of https://mcp.atlassian.com/v1/sse as a server endpoint will no longer be supported. We recommend updating any configured custom clients to point to /mcp: https://mcp.atlassian.com/v1/mcp/authv2
Source: https://support.atlassian.com/atlassian-rovo-mcp-server/docs/getting-started-with-the-atlassian-remote-mcp-server/
The README embedded inside the registry entry itself also still references https://mcp.atlassian.com/v1/mcp, so the metadata appears to predate the authv2 rollout.
Impact
- Clients pinned to the registry entry connect to
/v1/mcp and the OAuth 2.1 dynamic client registration handshake fails. - Only workaround is falling back to API-token auth, which many orgs gate or prefer to avoid for interactive use.
- Organizations that mandate sourcing MCP definitions from the GitHub MCP Registry cannot override the URL locally, so they have no client-side remediation.
Expected
The registry entry's remotes should advertise https://mcp.atlassian.com/v1/mcp/authv2 (and update the embedded README) so registry-pinned clients use the current OAuth flow.
Request
Can we get Github's com.atlassian/atlassian-mcp-server registry entry, managed by Atlassian with the authv2 endpoint and a process for keeping this updated?
