atlassian-browser-mcp

MCP server that wraps the upstream mcp-atlassian toolset with browser-cookie authentication via Playwright. Designed for Atlassian Server/Data Center instances behind corporate SSO (Okta, SAML, etc.) where API tokens are not available.

How it works

Authentication and serving are two separate processes — this is what keeps the MCP server from hanging:

1. Authenticate with the CLI (foreground, where a browser can open): atlassian-cli login <jira|confluence> runs Playwright, you complete SSO/MFA once, and cookies are saved to a per-service storage-state file.

2. The MCP server serves data only. It reads the saved cookies via a custom requests.Session subclass and never opens a browser. On a missing/expired session it fails fast with an AuthRequiredError telling you to run the CLI login — it does not block waiting for an interactive login.

⚠️ Earlier versions launched the login browser from inside the server. Because the server is detached and async, that blocked tool calls for minutes (often forever) and could deadlock Playwright's sync API on the event loop. The CLI/server split (allow_interactive=False on server sessions) removes that failure mode entirely.

The server monkey-patches JiraClient and ConfluenceClient constructors in mcp-atlassian to inject the browser-cookie session, giving full parity with the upstream tool surface.

Related MCP server: browser-devtools-mcp

Files

Reusing your real browser session (recommended)

To avoid re-entering your username/password + MFA on every login, seed the automation profile once from your real Chrome profile. The copy carries your existing SSO cookies (and saved logins / password-manager extension), so the first login is typically one-click or fully hands-free:

ATLASSIAN_SEED_FROM_CHROME_PROFILE=Default ./atlassian-cli login jira

Chrome 136+ blocks automation from driving the live profile in place, so a one-time copy into the dedicated profile dir is the supported way to inherit the session. The profile is never auto-deleted on an auth failure, so the long-lived session persists and re-login stays instant. Jira and Confluence keep separate cookie jars but share one seeded profile.

CLI usage

export JIRA_URL="https://jira.example.com"
export CONFLUENCE_URL="https://confluence.example.com"

./atlassian-cli login jira                       # one-time per service
./atlassian-cli jira get PROJ-123 --comments
./atlassian-cli jira search 'project = PROJ AND status = "In Progress"'
./atlassian-cli confluence get 123456789 --markdown -o page.md
./atlassian-cli confluence search 'release process' --space DEV

The CLI defaults to the real chrome channel (its seeded cookies are encrypted with a keychain key only Chrome can read); the MCP server defaults to chromium.

Usage

./run-atlassian-browser-mcp.sh

MCP server configuration

Add to your Claude Code, Cursor, or other MCP client configuration:

{
  "mcpServers": {
    "atlassian": {
      "command": "/path/to/atlassian-browser-mcp/run-atlassian-browser-mcp.sh",
      "env": {
        "JIRA_URL": "https://jira.example.com",
        "CONFLUENCE_URL": "https://confluence.example.com",
        "ATLASSIAN_USERNAME": "your.email@company.com"
      }
    }
  }
}

On first use (or when cookies expire), a Chromium window opens for SSO login. After login completes, the browser closes automatically and all MCP tool calls proceed using the saved session.

Environment variables

Requirements

• Python 3.11+

• uv (for dependency management)

• Chromium (installed automatically by Playwright)

• A graphical display (macOS, X11, or Wayland) — required for interactive SSO login

• Network access to your Atlassian instance

Troubleshooting