atlassian_loginLABSCO SUMMARY
It solves the authentication problem, not the tool problem.
The contribution here is narrow and real: corporate Atlassian instances behind SSO often cannot issue API tokens at all, and this makes them reachable by carrying the cookies your browser already has. The CLI-and-server split exists because the earlier design opened the login browser from inside the server and deadlocked tool calls for minutes — worth knowing, because it explains why you log in separately rather than on demand.
What it is
A wrapper around the upstream mcp-atlassian toolset that swaps token authentication for browser-cookie authentication via Playwright. It is aimed squarely at Atlassian Server and Data Center instances sitting behind Okta, SAML or similar, where the usual API token simply does not exist. Login and serving are deliberately separate processes: you authenticate once with a CLI in the foreground, and the server thereafter only reads the saved cookies.
What you get
atlassian_login— the login tool registered by the server itself- The upstream mcp-atlassian tool surface for Jira and Confluence, reached through patched clients that inject the browser-cookie session, so you get parity with the wrapped toolset rather than a reduced subset
- A command-line front end over the same auth core for scripting: log in per service, then fetch a Jira issue with its comments, run a JQL search, or get a Confluence page as Markdown
- Fail-fast behaviour on a missing or expired session: the server raises rather than blocking a tool call while it waits for an interactive login
- Separate cookie jars for Jira and Confluence sharing one browser profile, and an option to seed that profile once from your real Chrome profile so the first login is often one click
Requirements
A Jira or Confluence account you can log into through your identity provider, plus JIRA_URL and CONFLUENCE_URL — both required. Python 3.11 or higher and uv; the launcher script creates the virtualenv, installs dependencies and starts the server. Chromium is installed by Playwright. A graphical display is required for the interactive SSO login, so the first login must happen on a machine with a screen — headless environments are a documented failure mode. ATLASSIAN_LOGIN_TIMEOUT_SECONDS defaults to 300, ATLASSIAN_SSO_MARKERS covers Okta, ADFS, Azure AD, PingOne and Google SAML by default, and TOOLSETS controls which upstream toolsets are enabled.
Setup effort
Build from source — git clone https://github.com/GeiserX/atlassian-browser-mcp
USE CASES
01
Reading Jira from an instance with no API tokens
Log in once through your identity provider in the CLI, then let the server serve issues from the saved session.
02
Avoiding an MFA prompt on every login
Seed the automation profile from your real Chrome profile so the existing SSO session carries over and re-login stays instant.
03
Pulling a Confluence page into a document
Fetch the page as Markdown through the CLI and work from the converted text.
1 tool
Listed in project code.
BEFORE YOU INSTALL
What to know first
Tools you get
1 tool registered in the project's code. atlassian_login is the only tool this project registers itself. The Jira and Confluence tools come from the upstream mcp-atlassian package it wraps and are not in this count; how many you get depends on the installed mcp-atlassian version and on TOOLSETS, which enables all of them by default.
Requires
- Python 3.11+
- uv
- A graphical display (macOS, X11, or Wayland) for the SSO login
Where it runs
Both documented clients run the server on your machine.
INSTALLATION
Connect your client
You clone this one yourself.
Server setup
TERMINAL
git clone https://github.com/GeiserX/atlassian-browser-mcp
cd atlassian-browser-mcpSet your own Jira and Confluence base URLs — the CLI requires both:
TERMINAL
export JIRA_URL="<YOUR_JIRA_URL>"
export CONFLUENCE_URL="<YOUR_CONFLUENCE_URL>"Run the launcher once: it creates the .venv-atlassian-browser virtualenv, installs the dependencies and Chromium, then starts the server in the foreground. Stop it with Ctrl+C once it is running — your MCP client starts it itself later:
TERMINAL
./run-atlassian-browser-mcp.shLog in once per service in the browser window that opens:
TERMINAL
./atlassian-cli login jira
./atlassian-cli login confluenceMCP Clients
Claude Code, Cursor
JSON
{
"mcpServers": {
"atlassian": {
"command": "<YOUR_PATH_TO_ATLASSIAN_BROWSER_MCP>/run-atlassian-browser-mcp.sh",
"env": {
"JIRA_URL": "<YOUR_JIRA_URL>",
"CONFLUENCE_URL": "<YOUR_CONFLUENCE_URL>",
"ATLASSIAN_USERNAME": "<YOUR_ATLASSIAN_USERNAME>"
}
}
}
}<YOUR_PATH_TO_ATLASSIAN_BROWSER_MCP> is the full path to your clone. The first ./run-atlassian-browser-mcp.sh creates the virtualenv and installs dependencies (the CLI runs inside it); then log in once per service with ./atlassian-cli login — the server never opens a browser and fails fast with AuthRequiredError until a saved session exists.
