Description:
Currently, the Atlassian MCP server (mcp.atlassian.com) exclusively uses OAuth 2.1 with Dynamic Client Registration (DCR). While this works for standard clients (Claude Desktop, Cursor), it creates a significant blocker for Enterprise customers building internal, self-hosted AI interfaces.

Problem:

1. Strict Redirect Whitelisting: Customers cannot use their own production callback URLs (e.g., https://ai.<domain>.com/callback) because the MCP server only whitelists localhost and specific partner domains.

1. Lack of 3LO Support: Customers want to use a standard Three-Legged OAuth (3LO) app created in the Atlassian Developer Console. This allows them to manage their own Client ID/Secret, define specific scopes, and maintain a clear security boundary within their internal infrastructure.

1. Token Management: Enterprise security policies often require that OAuth tokens be exchanged and stored within their own managed middleware/proxy rather than relying on the DCR flow.

Requested Capabilities:

• Custom Redirect URI Whitelisting: Allow Org Admins to whitelist specific domains for MCP OAuth redirects.

• Static Client Support: Allow the MCP server to accept tokens generated by standard 3LO apps (non-DCR) created in the Developer Console.

• Service Account Integration: Better support for non-interactive flows that don't require a per-user browser redirect (building on the current API token beta).