atlassian

Teamwork Graph CLI: Install, Auth, First Queries Atlassian's Teamwork Graph CLI is a single program called twg that lets scripts and coding agents ask your Atlassian Cloud site questions from the terminal. You can use it by hand too. We installed version 1.4.2 on one of our Mac Studios, signed it in with an ordinary API token (no browser), and ran ten queries against wolfaenpak, our Atlassian test site. Nine of them answered in under two seconds. Rovo search, which searches all your connected tools at once, took five. We tripped over two details along the way. Asking twg jira workitem query for 200 work items gives you 100, with exit code 0 and no warning in the text. And twg confluence search text adds "last modified in the past 90 days" to your search. An older page won't come back unless you read the query it echoes. Both are easy to handle once you know, and the steps below show how. The paging loop in Step 4 pulled all 3,046 work items from our biggest test project, the same number Jira's own count API reports. Atlassian's own Community post introducing the Teamwork Graph CLI has close to 13,000 views. If you look after a Jira or Confluence site and you've ever exported a filter to a spreadsheet just to count something, twg can do that from a short script (Step 4). It's also what a coding agent like Claude Code uses to read your site. If you're the admin, the permissions screen in Step 2 is the part to read before your team installs it. [[steps]] 1. Install twg with Atlassian's installer and check it with twg doctor. 2. Sign in, either with OAuth in the browser or with an API token for scripts. 3. Run ten first queries against Jira and Confluence. 4. Use it from a script that pages properly. 5. Add the twg skills to Claude Code and ask it a question. > [!NOTE] > Prerequisites: an Atlassian Cloud site on Standard, Premium or Enterprise (Government Cloud is "Not available"); an account, and for scripts an Atlassian API token, that can see the projects you'll query; macOS (arm64 or x64), Linux (x64) or Windows (arm64 or x64); jq for Step 4. We tested twg 1.4.2 on macOS on 3 November 2026; we didn't try Linux or Windows. What we found when we ran it on our test site 1. Install is one binary and no runtime. The macOS installer downloaded a 100 MB file, checked its SHA-256 sum and was done. Atlassian's setup page confirms "The TWG CLI binary does not require a separate runtime (for example, no Node.js)." 2. An API token works for scripts. twg doctor printed "Authenticated successfully. API token is valid for the configured endpoint." with the token read from environment variables, and nothing was written to disk. 3. Most queries take about a second. Jira and Confluence reads took 0.75 to 1.5 seconds each. Rovo search, which searches across the connected products, took 5.0 seconds. 4. --limit stops at 100. --limit 200 gave exactly 100 items and hasNextPage: true. Following nextCursor got all 3,046. 5. Exit code 3 means "partial", and 0 doesn't always mean complete. Rovo search hit an HTTP 400 from Trello on our site, skipped it, returned five results and exited with 3. Atlassian's changelog says a partial search with more than 10 results can exit 0, so check the JSON too. 6. The agent got it right, and it was slow-ish. Claude Code reported 16 turns and 42 seconds for two simple questions. Four of its tool calls went on learning the commands from the skill and twg help, and most of the rest on reading the JSON twg had saved to a temp file. The answer matched Jira's REST API. What is Teamwork Graph CLI? The Teamwork Graph is the map Atlassian keeps of who works on what across your Atlassian apps and any connected tools (we wrote a plain explainer of the Teamwork Graph a few days ago). The CLI is a command line client for it. Atlassian's support page puts it this way: it's "a command line interface to the Atlassian Teamwork Graph and Cloud services", and "Install TWG CLI and your agent — Claude Code, Codex, Gemini, Cursor, and others — can query and act across all your Atlassian products and the Teamwork Graph on your behalf". In practice it has two kinds of commands. Native product commands (twg jira, twg confluence and about a dozen more) talk to each product's own API through Atlassian's gateway. Cross-product commands (twg rovo search, twg collaborators, twg context) use the graph itself. Atlassian marks the second kind [Enriched] in the help output, and that label matters for cost later on. The status is a bit muddled, and you should know before you roll it out. Atlassian announced the CLI as open beta in May 2026 and posted on the Community on 30 June that it "is generally available today". The support FAQ, updated 27 October, still says "In the current beta phase, Teamwork Graph CLI is free to install and use", and the developer changelog labels 1.4.2 "Beta release" even though 1.4.2 is what the stable channel installs. I think it's fair to treat it as a supported tool whose documentation is catching up, and I'd probably still pilot it with a few people first. Step 1: Install the Teamwork Graph CLI on macOS, Linux and Windows Atlassian's recommended one-liner for macOS and Linux is: bash <(curl -fsSL https://teamwork-graph.atlassian.com/cli/install) We downloaded the installer and read it before running it. It's an 817-line bash script, and it has flags to skip the login (--skip-login) or the agent skills (--skip-skills), plus --install-dir for the location. We put the binary in a scratch folder and skipped the login and the agent skills, so we could do both by hand: curl -fsSL https://teamwork-graph.atlassian.com/cli/install -o twg-install.sh bash twg-install.sh --install-dir /tmp/lz-twg-cli/bin --skip-login --skip-skills -y You should see something like this: Detected platform: darwin-arm64 Requested release: latest (v1.4.2) Will install twg to: /tmp/lz-twg-cli/bin/twg Downloading https://teamwork-graph.atlassian.com/cli/twg-darwin-arm64-v1.4.2 … Downloading https://teamwork-graph.atlassian.com/cli/SHA256SUMS-v1.4.2 -> … twg 1.4.2 installed at /tmp/lz-twg-cli/bin/twg ✅ Installed: /tmp/lz-twg-cli/bin/twg ✅ Added /tmp/lz-twg-cli/bin to ~/.zshrc Notice the last line. Even with --install-dir, the installer appended # Added by Teamwork Graph CLI installer and an export PATH=... line to our ~/.zshrc. That's fine on your own laptop, and less fine on a shared build machine, so check your shell profile after installing. We removed both lines afterwards. On Windows, Atlassian's page has you download and run a PowerShell script: curl.exe -fsSL https://teamwork-graph.atlassian.com/cli/install.ps1 -o twg-install.ps1 powershell -ExecutionPolicy Bypass -File .\twg-install.ps1 The same page warns: "Don't run the Windows installer from Git Bash, MINGW, WSL, or another bash-like shell." If you've seen a brew install line in an older blog post, the Homebrew tap is gone (fatal: repository 'https://github.com/atlassian/homebrew-twg/' not found, GitHub issue #7), so use the installer. Keep the TWG CLI updated: stable and beta channels Atlassian shipped 52 versions between 0.9.7 on 6 May and 1.4.2 (dated 27 October in the changelog), so you'll update often. twg update gets the latest stable build, and twg update --channel beta or --channel stable switches channels. The support page notes that "If you're on version 0.9.6 or earlier, twg update may not work correctly", in which case run the installer again. To remove it, twg uninstall --dry-run shows what would go, and Atlassian says twg uninstall "disables the schedule, revokes stored credentials, and removes the CLI and all local TWG configs." Step 2: TWG CLI auth: OAuth sign-in, or an API token for scripts For your own laptop, the normal route is twg login. Atlassian says it "displays a verification URL and a short user code, then opens your browser automatically", and the CLI then refreshes the OAuth token for you. Access tokens last 8 hours, and a small background helper (a macOS LaunchAgent, a Linux timer or a Windows scheduled task) runs every 12 minutes to refresh them before they expire. A script or a CI job has no browser, though. Atlassian's support pages describe OAuth 2.1 as "the only authentication method TWG CLI supports, except for Bitbucket commands". Atlassian's own install notes for agents (AGENTS.md) say something different: users can "set TWG_TOKEN and TWG_USER in their environment themselves (every command reads them directly — no login needed)". So we tried it with a normal Atlassian API token on wolfaenpak: export TWG_USER="you@example.com" export TWG_TOKEN="<your Atlassian API token>" export TWG_SITE="wolfaenpak" twg doctor The part of the output that matters: Resolved auth Endpoint: https://api.atlassian.com/graphql Site: wolfaenpak Auth method: API token Connectivity Status: ok Token: valid Auth source: TWG_TOKEN + TWG_USER Message: Authenticated successfully. API token is valid for the configured endpoint. auth.conf File: not found If yours says Token: valid and Auth source: TWG_TOKEN + TWG_USER, you're signed in. TWG_SITE takes your site prefix (the part before .atlassian.net), a hostname or a cloud ID. Nothing was saved to disk. In CI that's what you want, since the token stays in your secret store and goes away with the job. Keep in mind the token acts as that user, with that user's permissions, so a CI job should use an account that can see only what the job needs. We didn't test whether the admin permission switches in the next screenshot also apply to an API-token session. The page says it configures "the OAuth scopes", so I wouldn't assume they do.  If you're the admin, that's the page to look at before your team installs the CLI. There's no single on/off switch for the organisation. Atlassian's page says that to block it you "turn off Allow all permissions by default, clear the permissions in each category, save your changes, and choose Save and revoke sessions." Each command a user runs shows up in the audit log as "Invoked TWG CLI command", and the actor is always the person, even when an agent ran it. We covered the Delete permissions in our Team '26 Europe write-up if you want to lock those first. Step 3: Ten first Teamwork Graph CLI queries against Jira and Confluence These all ran against wolfaenpak, our test site, with the API token from Step 2. Times are the wall clock from time. 1. List your Confluence spaces, team spaces only. Without --type global the list mixes in everyone's personal space, named after the person. twg confluence space list --type global --limit 10 KEY Name Type Status URL ---------------------------------------------------------------------------- WFH WORK FOR HIRE global current https://wolfaenpak.atlassian.net/wiki/spaces/WFH JT JSM Test global current https://wolfaenpak.atlassian.net/wiki/spaces/JT DEMO Demo service project global current https://wolfaenpak.atlassian.net/wiki/spaces/DEMO ... PAYENG Payments Engineering global current https://wolfaenpak.atlassian.net/wiki/spaces/PAYENG REGREP Regulatory Reporting global current https://wolfaenpak.atlassian.net/wiki/spaces/REGREP OPRES Operational Resilience global current https://wolfaenpak.atlassian.net/wiki/spaces/OPRES 2. List your Jira spaces (projects). This one prints Jira's raw REST JSON even in the default text mode (avatar URLs included). You'll mostly pipe it through jq. twg jira space list --limit 10 { "projects": [ { "id": "11330", "key": "AUTOGOV", "name": "Automation Governance", "projectTypeKey": "software", ... 3. Run a JQL query. Any JQL you'd type in Jira works. LZPT is one of our test projects, so swap in your own key. (Jira calls them work items now, but the JSON still says issues.) twg jira workitem query --jql "project = LZPT ORDER BY updated DESC" --limit 5 { "issues": [ { "id": "21810", "key": "LZPT-218", ... "url": "https://wolfaenpak.atlassian.net/browse/LZPT-218", "summary": "WIDE-02", "status": { ... "name": "Done", ... "updated": "2026-10-31T11:34:46.047+0200" }, ... You get the usual Jira fields for each work item, from key and summary down to assignee and dates. The first one back was LZPT-218 ("WIDE-02"). It's Done and was last updated on 31 October. 4. Ask for JSON and keep only the fields you want. This is the form you'll use in scripts. --select trims the payload, and --output-summary none stops the CLI from wrapping big results in a summary. twg jira workitem query "project = LZPT AND statusCategory != Done ORDER BY updated DESC" \ --limit 5 -o json --output-summary none \ --select data.issues.key,data.issues.summary,data.issues.status.name { "apiVersion": "v2", "command": "jira.workitem.query", ... "data": { "issues": [ { "key": "LZPT-193", "summary": "CHAIN-2 build", "status": { "name": "In Progress" } }, { "key": "LZPT-186", "summary": "E1 · Linear Chain", "status": { "name": "To Do" } }, ... 5. Get one work item. We got this wrong at first: we asked for data.fields.summary, the path in Jira's REST API, and got back only the key. twg flattens the fields, and data is a list because get accepts several keys at once. twg jira workitem get LZPT-193 -o json --output-summary none \ --select data.key,data.summary,data.duedate,data.parent.key "data": [ { "key": "LZPT-193", "summary": "CHAIN-2 build", "duedate": "2026-05-15", "parent": { "key": "LZPT-186" } } ] The envelope around it also says where the data came from ("provenance": { "source": "teamwork-graph" }) and whether it's complete ("coverage": { "status": "complete" }). 6. Show a space's page tree. twg confluence tree CLOUD Cloud Migration Home [page] 323158295 current └── abc [page] 372965393 current Yep, our test space has a page called "abc". Your tree will look more respectable. 7. Search Confluence in plain words. Watch the line it prints back. twg confluence search text "migration runbook" --limit 5 Found 0 results for: type in (page, blogpost) AND text ~ "migration runbook" AND lastmodified >= now("-90d") ORDER BY lastmodified DESC search text adds lastmodified >= now("-90d") for you. If the page you want hasn't been touched in three months, it won't come back. Want the old pages too? Use number 8. 8. Search Confluence with CQL. This is the search I'd use most, because you write the whole query yourself and nothing gets added. twg confluence search query --cql 'type=page AND space in (PAYENG,REGREP,OPRES,IGDEMO) ORDER BY lastmodified DESC' --limit 5 Found 5 results for: type=page AND space in (PAYENG,REGREP,OPRES,IGDEMO) ORDER BY lastmodified DESC 1. RD004 Detailed Requirements - DEX header test (IGDEMO) [page] ... https://wolfaenpak.atlassian.net/wiki/spaces/IGDEMO/pages/430899266/... 9. Search everything at once with Rovo search. This is the cross-product one, and it's [Enriched]. twg rovo search "payment incident" --limit 5 Warning: Rovo search DOWNSTREAM_ERROR: Problem while calling endpoint trello: 400 Bad Request ... (printed twice) Warning: Skipped: Trello (HTTP 400). Only this search is affected: every other source was searched, and search-code, bb and other twg commands are unaffected. Top 5 results (limit 5; more matches exist; skipped: Trello; partial results) 1. Payments Engineering Home Source: confluence · Type: page 2. CL probe CL-T-fingerprint Source: jira · Type: issue ... It took 5.0 seconds and exited with code 3. Trello failed, and the search still came back with Confluence pages and Jira work items in one list. 10. See who you work with most. Also [Enriched], and the funniest result of the run. twg collaborators --limit 5 ✓ Found 5 collaborator(s). 1. Sentinel Vault: Document Control & Approvals for Confluence score 0.167 2. CogniRunner: AI Workflow Validators & Agents for Jira score 0.042 3. LeanZero Management: Gantt Charts & PPM for Jira score 0.006 4. Gabriela Perdum score 0.003 5. Automation for Jira score 0 The account we ran it as is the admin of our test site, where we install and test our own Forge apps all day. So its three closest colleagues are app bots, and I come fourth. On a normal account you'll see people.  Step 4: Run twg from a shell script or a CI job In a script you have to handle paging and exit codes yourself. The interactive output hides both. Page past 100 results Our biggest test project, COGTEST, has 3,046 work items. Ask for 200: twg jira workitem query "project = COGTEST" --limit 200 -o json \ --output-summary none | jq '(.data.issues|length), .pageInfo.hasNextPage' 100 true You asked for 200. You got 100, and the exit code was 0. You should see the same 100 and true on any project with more than 100 work items. Someone reported the same thing on Atlassian's public twg-cli GitHub tracker (issue #11) against an older version, and it still happens on 1.4.2. The good news is that the JSON tells you there's more: pageInfo.hasNextPage is true, and pageInfo.nextCursor holds the cursor for the next page. Note that pageInfo sits at the top level of the response, next to data, and not inside it. So a loop does the job. Save this as all-keys.sh: #!/usr/bin/env bash # Page through a JQL query with twg and print every work item key. set -euo pipefail jql="$1"; after="" while :; do page=$(twg jira workitem query "$jql" --limit 100 ${after:+--after "$after"} \ -o json --output-summary none) echo "$page" | jq -r '.data.issues[].key' [ "$(echo "$page" | jq -r '.pageInfo.hasNextPage')" = "true" ] || break after=$(echo "$page" | jq -r '.pageInfo.nextCursor') done Then run it: chmod +x all-keys.sh ./all-keys.sh "project = COGTEST ORDER BY key ASC" | wc -l 3046 The loop should print the same number Jira's count API returns for that JQL. It took 31 seconds for 31 pages. To check it, we asked Jira's own REST API for the count of the same JQL (POST /rest/api/3/search/approximate-count), which returned {"count":3046}. Every key was unique, from COGTEST-1 to COGTEST-3086 (some keys in between were deleted, so the last number is higher). Read the exit code The developer changelog says a search returns exit code 3 when it's incomplete and has 10 or fewer usable results. Rovo search did exactly that in Step 3. Since 1.3.9 (20 October) an incomplete search with more results can exit 0, so don't treat 0 as proof that every source answered. Check the partial flag in the JSON as well: twg rovo search "payment incident" --limit 5 -o json --output-summary none > results.json case $? in 0) echo "complete" ;; 3) echo "partial results, check the warnings" ;; *) echo "twg failed" ; exit 1 ;; esac jq -e ".resultInfo.partial == true" results.json >/dev/null && echo "resultInfo.partial is true" partial results, check the warnings resultInfo.partial is true On our site results.json had "resultInfo": {"partial": true, "returned": 5, ...} plus a failures list naming Trello. Keep --output-summary none in there: without it, -o json wrote a YAML summary to the file, which jq can't read. Two settings for CI and agents Atlassian's agent notes ask you to set TWG_AGENT_DEFAULTS=1 when an agent or a non-interactive host runs twg. And twg env --exec -- <program> (added in 1.3.8) starts another program with the selected login profile's credentials, which saves you exporting them by hand. If you're upgrading an older script, twg api was removed in 1.3.5 on 1 October, and calling it now fails with error: unknown command 'api' (GitHub issue #29). Step 5: Add the TWG CLI skill to Claude Code and other coding agents A skill is a folder of instructions a coding agent reads to learn a tool. The full installer adds twg's skills for the agents it finds on your machine. We wanted them in one project only, so we made an empty folder and ran: twg skills install --local --agent claude -y It printed nothing. It took 0.4 seconds. It created four skills (twg, twg-jira, twg-confluence, twg-setup) as links to the CLI's own copy. They went into .agents/skills/, the shared folder Atlassian's skills page uses for every agent, and into .claude/skills/ for Claude Code. You should see those four folder names if you run ls .claude/skills. Atlassian's support page names two skills (twg and twg-workflows), so expect the list to change between versions. Then we asked Claude Code a question from that folder, allowing it to run only twg commands: export TWG_AGENT_DEFAULTS=1 claude -p "Using the twg CLI, tell me which work items in the Jira project LZPT are not done yet (just the count and the five most recently updated), and which Confluence page in the PAYENG space is the most recently modified. Keep the answer short." \ --model sonnet --max-turns 15 --allowedTools "Bash(twg:*)" "Skill" "Read" It loaded the twg skill and read twg help-map and twg help describe "jira workitem query" to learn the commands. Then it ran the JQL with statusCategory != Done and read the full JSON from a temporary file. twg had written it there because in agent mode it summarises big outputs and saves the rest to disk. Its answer: In LZPT, 81 work items are not done. [...] 1. LZPT-193 "CHAIN-2 build" (updated 2026-10-31) 2. LZPT-186 "E1 · Linear Chain" (2026-10-29) [...] In PAYENG, "Payments Engineering Home" (id 323190936) is the only page in the space, so it is the most recently modified by default. Both answers were right. Jira's count API returned 81 for the same JQL, and Confluence's REST API listed exactly one page in PAYENG. Claude Code reported 16 turns, 42 seconds and $0.31 for the run (model claude-sonnet-5-5). Four of its calls went on learning the CLI, which has 567 commands by Atlassian's count in the GA post. Four more were refused: three because we'd only allowed twg, Read and Skill (it tried jq and grep), and one because the file twg saved was outside the project folder, where Claude Code won't search. Allowing Bash(jq:*) too, or naming the exact command in your project's instructions, should save turns. If you use Claude Code's plugin marketplace instead, Atlassian publishes an Atlassian Teamwork Graph CLI plugin that sets this up with /twg-setup. TWG CLI vs MCP: when an agent should use which Atlassian also runs the Atlassian MCP server, which gives agents the same kind of access through the Model Context Protocol. Their comparison page has a clear rule: "Use Atlassian MCP when your agent runs in a browser, on mobile, or as a cloud-hosted agent. Use Teamwork Graph CLI when you're building scripts, CI/CD pipelines, or other repeatable workflows. Use whichever you prefer when your agent runs on your desktop with terminal access". I think that's a fair rule, and for an admin who mostly wants reports, the CLI is probably the easier one to start with. What I'd add from our own numbers: many MCP clients load every tool definition into the agent's context up front. When we measured that, 145 MCP tool definitions cost 40,784 tokens before the agent did anything. Claude Code is an exception: since January 2026 it holds MCP tool definitions back until it searches for them. The CLI's skills are a few hundred lines. The agent looks up commands as it needs them, so Claude Code spent turns on twg help. Fewer tokens up front, more turns per question. Atlassian claims "44% better answers using 48% fewer tokens" with the CLI, from what it calls "an internal study"; it hasn't published the method, and we haven't reproduced it. For the admin side of the MCP server, our MCP permissions and data security policy guide covers the switches.  Teamwork Graph CLI or the Teamwork Graph API? If you're building a Forge app, you don't shell out to twg. You call the Teamwork Graph's GraphQL API from your app's code, and we walked through that in our Teamwork Graph API tutorial for Forge and Rovo agents. The CLI is for whatever runs on a computer with a terminal, you included. You'll notice from twg doctor that the CLI talks to the same GraphQL gateway (https://api.atlassian.com/graphql). What each one can see still depends on how it signs in: your user account and the CLI's permissions for twg, and the app's scopes for a Forge app. What it costs to run Reading a Jira work item or a Confluence page is free, and Atlassian's FAQ says that stays free: "Requesting single product context, such as looking up a Jira work item or Confluence page's content" is in the always-free list. The [Enriched] commands are different. Atlassian's command catalogue (28 August) marks 52 commands Enriched, including twg rovo search and twg collaborators (both used above), against 620 free ones. The FAQ says that "With 90 days advance notice, certain enriched, value-added commands will be billed with at least 1 Rovo credit per call", and that Rovo credit allowances apply from 3 December 2026. Extra usage isn't billed unless your organisation opts in. If you want to see how far a monthly allowance goes, we measured Rovo credits per action on our own site. If it didn't work 1. ✖ Access denied — credentials were NOT saved. with "Your TWG CLI EAP access has been revoked or is not enabled." This comes from an early-access build. Atlassian's fix is to update the CLI and run twg setup again (the command that installs the skills, signs you in and checks the setup). 2. `/dev/fd/11: line 1: syntax error near unexpected token newline'`** during install. The install URL served an HTML page instead of the script (GitHub issue #4, since fixed). Download the script to a file first and check it starts with #!/` before you run it. 3. **error: unknown command 'api'. twg api was removed in 1.3.5. Use the product commands (twg jira ..., twg confluence ...) instead. 4. You asked for 200 results and got 100. Page with --after and pageInfo.nextCursor, as in Step 4. 5. A Confluence search finds nothing you know is there. search text only looks at pages modified in the last 90 days. Use twg confluence search query --cql without a date clause. 6. Exit code 3. Partial results: one source failed or the result was cut short. Read the warnings, keep the results if they're good enough, and log it. An exit code of 0 can also hide a partial search, so check resultInfo.partial. 7. twg skills refresh fails with a 404 on 1.4.2. That's open as GitHub issue #32. The skills from twg skills install still worked for us. What you have now [[takeaways]] - twg installed and checked with twg doctor, and your shell profile checked for the line the installer adds. - A sign-in for people and one for scripts. OAuth in the browser for you, and an API token in the TWG_* variables for scripts, on an account that sees only what it needs. - Ten queries you can reuse, including the CQL form that searches all of time and the JSON form with --select. - A paging loop that got all 3,046 work items where --limit 200 gave 100, and exit-code handling that treats 3 as partial. - An agent that can read your site, with skills installed in one project and Claude Code answering a real question correctly. Next, I'd pick one report you rebuild by hand each week (the open bugs per component, say, or the pages nobody has touched in a year) and turn it into a twg script. Did twg do something weird on your site? Tell me and I'll add it to the list above. --- <!-- lz-footer --> Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net, and if you're planning a migration or a Forge app, that's what we do: leanzero.net.

Connecting Jira, Confluence and Bitbucket to Claude Code with Atlassian's Rovo MCP server --- title: "Connecting Jira, Confluence and Bitbucket to Claude Code with Atlassian's Rovo MCP server" published: true tags: mcp, claude, atlassian, ai canonical_url: agenttaskatlas.com description: "claude mcp add on Atlassian's v2 endpoint, OAuth sign-in from /mcp, a shared .mcp.json, API-token auth for headless setups, and keeping write tools behind a prompt." --- Atlassian runs an official, hosted MCP server (the Atlassian Rovo MCP Server), so there is nothing to install locally. Claude Code connects to https://mcp.atlassian.com/v2/mcp over HTTP and acts with your own Atlassian Cloud permissions. Atlassian's README says v2 is the recommended endpoint for new setups. The steps below summarize the official docs (the Atlassian MCP Server README, Atlassian Support's API token guide, and the Claude Code docs on MCP and permissions), checked on 2026-10-26. Client CLIs and admin menus change, so if something differs on your version, the linked docs win. The original version of this guide lives at AgentTask Atlas: How to connect the Atlassian Rovo MCP server to Claude Code. 1. Check what you need - An Atlassian Cloud site with Jira, Confluence, Jira Service Management, Bitbucket or Compass. - A browser for the OAuth 2.1 sign-in. Headless setups can use an API token instead, but only if an org admin has enabled API-token authentication (Atlassian Administration → Rovo → Rovo MCP server → Authentication). 2. Add the server This is the command Atlassian's README gives for Claude Code: claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp Add --scope user to make it available in every project, or --scope project to share it through .mcp.json. 3. Sign in with OAuth Start a Claude Code session and run /mcp, select atlassian and complete the browser sign-in: claude /mcp Until you do, claude mcp list shows the server as needing authentication. Access is limited to what your Atlassian account can already see. 4. Or share it with the team in .mcp.json This is the entry from Atlassian's own repository: { "mcpServers": { "atlassian": { "type": "http", "url": "https://mcp.atlassian.com/v2/mcp" } } } Keep "type": "http". Claude Code reads an entry with a url but no type as a stdio server and skips it. Each teammate still signs in with their own account from /mcp. 5. Headless: authenticate with an API token Create a scoped personal API token, base64-encode email:api_token as Atlassian's token guide shows, and pass it as a Basic Authorization header (a service account key uses Bearer instead): echo -n "your.email@example.com:YOUR_API_TOKEN" | base64 claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp \ --header "Authorization: Basic BASE64_ENCODED_EMAIL_AND_TOKEN" Two things to know: Jira Service Management tools only work with token auth, and some Compass tools are not available with it. 6. Keep write tools behind a prompt The server can create and update Jira issues, Confluence pages and Bitbucket content. An ask rule in .claude/settings.json makes Claude Code confirm every Atlassian tool call: { "permissions": { "ask": [ "mcp__atlassian__*" ] } } Don't add an allow rule for mcp__atlassian__* unless you trust every write it can make. Good to know - The delete_jira and manage_jira permission groups are disabled by default; an admin has to turn them on. Leave them off unless you need them. - Tokens are not bound to one cloudId and skip the OAuth domain allowlist, so prefer OAuth for interactive use and keep tokens scoped to the projects the agent needs. - Atlassian suggests putting your Jira project key, Confluence space and cloudId in AGENTS.md so the agent makes fewer discovery calls. - Every tool call is recorded in your organization's audit log (Atlassian Administration → Insights → Audit log). - The legacy SSE endpoint (/v1/sse) stopped being supported after 30 June 2026. Point old configs at /v2/mcp. More on MCP in Claude Code New to MCP in Claude Code? The general guide covers transports, scopes and how to confirm a server connected: How to add an MCP server to Claude Code. I keep a small catalog of MCP servers and Agent Skills organized by dev task, with the install step, credentials, permissions and documented clients taken from each project's official docs. The Atlassian Rovo MCP Server entry is based on official docs, not hands-on tested, so always check the source repo. The catalog is also available as a free, read-only remote MCP server (no account or key): claude mcp add --transport http agenttask-atlas https://agenttaskatlas.com/api/mcp --- Disclosure: I run AgentTask Atlas, the catalog linked above. This post was drafted with AI assistance from the guide on agenttaskatlas.com, whose steps summarize the official Atlassian and Claude Code docs as of 2026-10-26.

The Definitive Guide to Atlassian MCP !The Definitive Guide to Atlassian MCP TL;DR - The official Atlassian MCP server connects AI developer tools and language models directly to Jira, Confluence, and the Teamwork Graph through Anthropic's open Model Context Protocol standard. - Version 2 of the Atlassian MCP server provides over 220 tools with dynamic on-demand tool discovery to prevent context window bloat and reduce token consumption by up to 25%. - Direct client-to-server MCP connections expose organizations to security vulnerabilities, including prompt injection, uncontrolled data exfiltration, and credential fragmentation. - Operating an intermediate control plane like Bifrost enables centralized access control, tool filtering, semantic caching, and audit logging for Atlassian MCP traffic. - Endpoint agents like Bifrost Edge extend gateway governance directly to employee laptops, discovering and controlling local MCP configurations across development fleets. The Model Context Protocol (MCP) is an open architectural standard that formalizes how artificial intelligence clients discover and execute tools hosted by external systems. As engineering organizations adopt autonomous agents, the Atlassian MCP server has emerged as a critical bridge connecting systems like Jira, Confluence, Bitbucket, and Compass to developer interfaces. Bifrost, an open-source AI gateway written in Go by Maxim AI, provides the control plane required to manage, observe, and secure these MCP connections at enterprise scale. This guide examines how the Atlassian MCP ecosystem functions, evaluates official cloud versus self-hosted implementations, analyzes production security risks, and demonstrates how to govern tool execution effectively. What is the Atlassian MCP Server? The Atlassian MCP server is a standardized integration layer that allows external AI clients to query and modify Atlassian Cloud data using natural language commands. Built on the Model Context Protocol initiated by Anthropic, the server translates tool calls issued by large language models into authenticated REST and GraphQL requests across Atlassian products. +-------------------------------------------------------------+ | AI Client / Agent | | (Claude Desktop, Cursor, VS Code, CLI) | +-------------------------------------------------------------+ | MCP Protocol (JSON-RPC) | v +-------------------------------------------------------------+ | Atlassian MCP Server (Remote Cloud) | | https://mcp.atlassian.com/v2/mcp | +-------------------------------------------------------------+ | OAuth 2.1 / Scoped User Auth | v +-------------------------------------------------------------+ | Atlassian Cloud APIs | | Jira | Confluence | Bitbucket | Teamwork Graph | +-------------------------------------------------------------+ Historically, connecting generative models to Jira or Confluence required custom API wrappers, rigid prompt templates, or third-party webhooks. Developers had to copy ticket descriptions manually into web interfaces or write custom scripts that lacked standardized schema validation. The Model Context Protocol establishes a bidirectional JSON-RPC interface between hosts (AI user interfaces such as Claude Desktop, Cursor, or terminal agents) and tools. Atlassian developed an official cloud-hosted remote MCP server (accessible at https://mcp.atlassian.com/v2/mcp) that operates on Atlassian infrastructure. When an engineer instructs an assistant to inspect an ongoing sprint or summarize product requirements, the client communicates with the MCP server to inspect tool definitions, invoke relevant operations, and receive structured context. The Atlassian MCP implementation relies heavily on the Atlassian Teamwork Graph. Rather than treating Jira issues and Confluence pages as isolated database entities, the Teamwork Graph models relationships between pull requests, service definitions, epics, sprint velocity, meeting recordings in Loom, and engineering ownership. When an agent queries a Jira work item, the Atlassian MCP server can return not only the ticket body, but also the linked Git branches, recent deployments, and parent architectural documents in a single structured traversal. Core Capabilities Across Jira, Confluence, and the Teamwork Graph The Atlassian MCP server supports reading, searching, creating, and updating artifacts across the Atlassian Cloud catalog through unified natural language directives. Rather than requiring isolated integrations for each service, a single MCP connection gives agents access to over 220 tools spanning development tracking, knowledge bases, and strategic planning. Version 2 of the Atlassian MCP server handles tool discovery dynamically. Earlier MCP implementations registered every available tool definition in the model's initial system prompt. With more than 200 granular functions, registering every schema simultaneously consumed tens of thousands of prompt tokens before a user typed a single word. The revised architecture registers a minimal primary tool set and exposes a runtime discover utility. The language model uses this utility to locate specialized tools only when required by the user's intent, reducing prompt token consumption by up to 25% while expanding functional reach. | Product Domain | Primary MCP Tools | Typical Agent Operations | Common Use Cases | | :--- | :--- | :--- | :--- | | Jira Software & JSM | search_issues, create_issue, update_issue, transition_issue, add_comment | Query JQL filters, update sprint statuses, parse bug reports, assign tickets | Automated sprint grooming, triage of incoming incidents, release task tracking | | Confluence | search_content, read_page, create_page, update_page, get_space | Fetch technical specifications, summarize architecture pages, draft release notes | Synchronizing code architecture docs, onboarding assistance, knowledge synthesis | | Bitbucket & Compass | get_pull_request, query_components, get_service_dependencies | Map microservice dependencies, inspect linked pull requests, verify deployment state | Root-cause analysis during outages, automated dependency audits | | Loom | get_recording, get_transcript, get_meeting_actions | Extract action items from recorded video transcripts, parse customer calls | Converting design demos into structured Jira tickets and feature specs | | Strategy & Talent | query_goals, search_focus_areas, map_project_priorities | Connect day-to-day tickets to high-level corporate goals and assigned team rosters | Executive status reporting, alignment tracking across engineering teams | Across enterprise deployments, approximately one-third of all MCP calls are write operations rather than passive document retrievals. Autonomous agents commonly draft multi-ticket epic breakdowns from unstructured notes, transition Jira workflows upon pull request approval, and log structured root-cause analyses back to Confluence. !An intricate isometric technical interface illustrating structured digital pathways connecting project task blocks and d Cloud Remote MCP vs. Self-Hosted MCP Servers Organizations evaluating Atlassian integration via MCP must choose between Atlassian's official cloud-hosted remote server and community-maintained, self-hosted alternatives. The architectural differences dictate network topology, credential management, and compatibility with on-premise environments. The official remote server runs directly on Atlassian Cloud infrastructure (https://mcp.atlassian.com/v2/mcp). It uses OAuth 2.1 authentication with Proof Key for Code Exchange (PKCE), ensuring that access tokens inherit the precise role-based permissions of the authenticated human operator. The server updates automatically as Atlassian expands its API surface, and calls count against standard cloud tier rate limits or Atlassian Rovo credits. However, this official deployment is restricted strictly to Atlassian Cloud tenants; it cannot reach Jira Data Center or self-hosted Confluence installations behind private corporate firewalls. For self-hosted Atlassian Data Center installations, engineering teams deploy open-source local MCP servers, such as mcp-atlassian. These servers run locally on developer workstations as stdio processes (standard input/output over CLI) or as containerized microservices within a private virtual private cloud (VPC). +------------------------------------------------------------------------+ | Deployment Trade-Offs | +------------------------------------------------------------------------+ | Feature | Official Remote Server | Self-Hosted Servers | +------------------------------------------------------------------------+ | Target Environment | Atlassian Cloud only | Data Center, Server, | | | | and Cloud | | Transport Protocol | Streamed HTTP / SSE | stdio or Local SSE | | Authentication | OAuth 2.1 with PKCE | Personal Access Tokens| | Maintenance Overhead | Zero (managed cloud) | High (manual upgrades)| | Tool Breadth | 220+ products, Graph | 20-50 core tools | | Network Ingress | Outbound to Internet | Fully Private / Local | +------------------------------------------------------------------------+ While self-hosted servers provide critical access for regulated teams running isolated Data Center instances, they require local administration, manual updates when schemas change, and static personal access token (PAT) configuration that introduces credential storage risks. How to Configure Atlassian MCP in AI Clients Connecting AI clients to the Atlassian MCP server involves establishing a client configuration entry that points to the remote endpoint or local binary, followed by completing an authentication handshake. Configuring Claude Desktop For Claude Desktop, configure the remote MCP endpoint by modifying the claude_desktop_config.json file. Because Claude Desktop supports remote MCP connections via Server-Sent Events (SSE) or standardized transport bridges, add the server definition to the mcpServers object: { "mcpServers": { "atlassian": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-remote", "https://mcp.atlassian.com/v2/mcp" ] } } } Upon starting the client, Claude opens an OAuth 2.1 consent screen in the user's default browser. Once authorized, the client links the user's Atlassian session, applying their existing permissions across Jira and Confluence. Configuring Cursor and VS Code Development environments such as Cursor, Visual Studio Code, and coding agents support Model Context Protocol integrations directly in their environment settings. Within Cursor, developers can configure the server via .cursor/mcp.json or through the interactive graphical interface: { "mcpServers": { "atlassian-cloud": { "url": "https://mcp.atlassian.com/v2/mcp", "auth": { "type": "oauth2" } } } } Self-Hosted Data Center Configuration For engineering teams running on-premise Jira Data Center instances, configuration points to a local Python or Node runtime using personal access tokens: { "mcpServers": { "jira-datacenter": { "command": "uvx", "args": ["mcp-atlassian"], "env": { "JIRA_URL": "https://jira.internal.enterprise.com", "JIRA_PERSONAL_ACCESS_TOKEN": "ATATT3xFfGF0...", "CONFLUENCE_URL": "https://confluence.internal.enterprise.com", "CONFLUENCE_PERSONAL_ACCESS_TOKEN": "ATATT3xFfGF0..." } } } } While individual setup takes only minutes, unmanaged developer configurations across hundreds of machines rapidly introduce credential sprawl, lack of audit visibility, and compliance vulnerabilities. Enterprise Security, Privacy, and Governance Risks Deploying the Atlassian MCP server across engineering teams introduces structural architectural risks that bypass traditional corporate API perimeter defenses. Because Model Context Protocol grants language models programmatic read and write access to internal documentation and issue trackers, security teams must account for several critical exposure vectors. Direct Client-to-MCP Topology (High Risk): [Client/Laptop] ----(Raw Prompt + Injected Data)----> [Atlassian Cloud] | +--> Hardcoded PATs on disk +--> Ungoverned Tool Execution (Accidental Deletes) +--> Zero Central Audit Trails Governed Gateway Topology (Zero Trust): [Client/Laptop] ----(Encrypted)----> [Bifrost Gateway] ----(Policy Enforced)----> [Atlassian MCP] | +-------------+-------------+ | Virtual Keys & Tool Filter| | PII & Secret Redaction | | Immutable Audit Logs | +---------------------------+ Prompt Injection and Tool Poisoning Language models remain fundamentally susceptible to prompt injection, including indirect injection through untrusted text. If an autonomous agent reads a public Jira ticket containing malicious instructions (for example, hidden HTML comments instructing the model to fetch and export internal Confluence credentials), the agent may execute those commands using the authorized user's permissions. Because the Atlassian MCP server trusts instructions signed by the authenticated session, an injected prompt can command the model to query internal strategy docs and paste confidential summaries into public ticket comments. Accidental Data Mutation and Cascading Deletions Roughly 30% of MCP traffic represents mutation actions. Unchecked autonomous agents running loops in tools like Claude Code or Codex can execute destructive operations based on ambiguous prompts. An instruction such as "clean up outdated backlog items" can cause an agent to close, reassign, or delete dozens of active user stories if strict confirmation boundaries and tool execution rules are absent. Token Sprawl and Hardcoded Secrets Self-hosted MCP installations frequently store static personal access tokens in plaintext configuration files on developer laptops. If a laptop is compromised, or if a developer pushes a local configuration directory to a public repository, those long-lived Atlassian credentials provide persistent access to internal corporate data. Context Window Exhaustion and Cost Escalation When language models retrieve complete Jira issue histories, rich text fields, and extensive Confluence pages, the raw payloads can consume tens of thousands of tokens per API call. In multi-turn chat sessions, re-sending massive retrieved context back to foundational model providers like Anthropic or OpenAI multiplies API inference expenses exponentially. !A multi-layered transparent glass security gateway inspecting, filtering, and organizing dynamic packets of code and dat Governing Atlassian MCP with Bifrost To mitigate data leakage, control token costs, and enforce strict authorization policies, enterprises route Atlassian MCP interactions through Bifrost. Rather than allowing local clients to connect directly to external endpoints, Bifrost serves as a centralized MCP gateway and policy engine. +---------------------------------------------------------------+ | Engineering Fleet | | (Cursor, Claude Code, VS Code, Browser AI) | +---------------------------------------------------------------+ | Governed by Bifrost Edge Endpoint Agent | v +---------------------------------------------------------------+ | Bifrost AI Gateway | | - Virtual Keys: per-team quotas, budgets, and rate limits | | - Tool Groups: filter out destructive Jira write actions | | - Content Guardrails: redact API keys, PII, and credentials | | - Semantic Caching: deduplicate repeated Confluence reads | | - OTLP Traces: full request/response auditing | +---------------------------------------------------------------+ | v +---------------------------------------------------------------+ | Upstream Atlassian MCP Server | | https://mcp.atlassian.com/v2/mcp | +---------------------------------------------------------------+ Centralized MCP Proxying and Tool Filtering Bifrost operates as both an MCP client and an MCP server. It connects upstream to the Atlassian MCP server and exposes a unified, managed endpoint down to developer tools. Using virtual keys, platform engineers configure granular access profiles for different teams. An organization can grant junior contractors a virtual key that allows only read-only Jira search tools, while senior developers receive keys authorized for issue transitions and documentation updates. Bifrost enforces MCP tool filtering at the network layer: unauthorized tools are stripped from the advertised schema, preventing models from ever attempting dangerous invocations. Cost Optimization via Code Mode and Semantic Caching When agents query documentation across large Confluence spaces, Bifrost's semantic caching captures repeated identical or semantically similar queries. If multiple developers ask their respective IDE assistants to summarize the same onboarding specification or architecture guidelines, Bifrost returns cached completions directly, eliminating redundant model inference and Atlassian API usage. Furthermore, Bifrost supports Code Mode. Instead of requiring a model to engage in multi-turn JSON-RPC conversation loops to filter and aggregate Jira issues, Bifrost enables the AI to write brief execution scripts that run in an isolated execution sandbox. This programmatic orchestration cuts round-trip network hops, yielding up to 50% fewer tokens and 40% lower latency during complex multi-step research tasks. Real-Time Guardrails and PII Redaction Beyond routing, Bifrost applies governance and security controls (virtual keys, budgets, guardrails, audit logs) centrally, and Bifrost Edge extends that same governance and security to AI traffic on employee machines, with endpoint enforcement on each device. Bifrost inspects MCP inputs and outputs through configurable enterprise guardrails. Before text retrieved from a Confluence page reaches an external model provider, automated secrets detection scrubs accidental AWS credentials, private keys, and database connection strings. Similarly, outbound prompts are scanned to ensure developers do not transmit customer personally identifiable information (PII) into unvetted model pipelines. Extending Control to the Fleet with Bifrost Edge A gateway can only govern requests explicitly configured to pass through it. In corporate environments, developers frequently install new desktop extensions, local CLI tools, or browser-based AI assistants that bypass proxy environment variables, generating ungoverned shadow AI. Bifrost Edge solves this visibility gap by operating as a native endpoint agent across macOS, Windows, and Linux. Built as a lightweight background service, Edge transparently intercepts AI traffic and redirects it through the central Bifrost gateway. Through MCP governance and app governance, security administrators gain a real-time fleet inventory of every MCP server configured inside tools like Claude Desktop, Cursor, and terminal agents. Administrators can enforce allow/deny lists across the organization, instantly neutralizing unauthorized local MCP servers before data leaves developer machines. Organizations roll out the Bifrost Edge agent fleet-wide using standard mobile device management (MDM) frameworks such as Microsoft Intune, Jamf, and Kandji, ensuring unified enterprise compliance without requiring manual per-seat configuration. Production Best Practices for Atlassian MCP Deployment To maximize productivity while maintaining zero-trust security boundaries, platform teams should adopt several operational best practices when rolling out Atlassian MCP across engineering units. 1. Enforce Principle of Least Privilege via OAuth Scopes Avoid deploying shared administrative personal access tokens for local developer MCP servers. Rely on official OAuth 2.1 authentication where every tool invocation operates strictly within the active user's existing Atlassian permissions. If an employee lacks access to a confidential Jira security project, their AI assistant must be prevented from reading those tickets via MCP. 2. Implement Confirmation Gates on Destructive Actions Configure AI clients and MCP gateways with mandatory human-in-the-loop approvals for mutation operations. While allowing an agent to search and read Confluence autonomously is generally low risk, operations like delete_issue, bulk_transition, or create_page should require explicit confirmation in the developer's interface before execution. Low Risk (Auto-Approve): - search_issues_by_jql - read_confluence_page - get_sprint_status High Risk (Require Human Approval): - transition_jira_issue - delete_issue - update_confluence_page 3. Establish Immutable Audit Logging Every interaction conducted through MCP must be traceable to satisfy SOC 2, HIPAA, and ISO 27001 regulatory frameworks. Route all gateway traffic to centralized logging backends using Bifrost's audit logs and OpenTelemetry (OTLP) collectors. Audit entries should capture: - The exact virtual key and authenticated human identity - The timestamp and target MCP tool name - The raw parameter inputs and sanitized return payloads - Total prompt and completion token consumption 4. Monitor Token Consumption and Cost Allocations Atlassian MCP calls consume API rate limits and foundational LLM tokens rapidly. Use Bifrost's budget and limit controls to establish monthly spend ceilings per team or repository. When a development team approaches its allocated threshold, the gateway throttles non-essential retrieval requests to prevent surprise cloud bills. Frequently Asked Questions What permissions does the Atlassian MCP server require? The Atlassian MCP server uses OAuth 2.1 to inherit the authenticated user's exact Atlassian permissions. It cannot access Jira projects, private Confluence spaces, or Bitbucket repositories that the user cannot view in their browser. Administrators can also configure domain-level allowlists in Atlassian Administration to control which external AI clients can connect to their tenant. Does Atlassian MCP support on-premise Jira Data Center? The official Atlassian remote MCP server supports only Atlassian Cloud. Organizations running self-hosted Jira Data Center or Confluence Server must deploy community-maintained, self-hosted MCP servers (such as mcp-atlassian) within their private network, authenticating via Personal Access Tokens. How does Atlassian MCP prevent context window exhaustion? Version 2 of the Atlassian MCP server implements dynamic tool discovery. Instead of transmitting schemas for all 220+ available tools in the initial prompt, the server exposes a core set of navigation tools and lets the AI model query the broader catalog on demand using a discover tool. This architecture saves up to 25% in token overhead compared to legacy implementations. Can AI agents delete or overwrite Jira tickets through MCP? Yes, the Atlassian MCP toolset includes write and delete capabilities, including issue deletion, status transitions, and page updates. To prevent unintended modifications, platform teams should enforce human confirmation in their AI client settings or use Bifrost virtual keys to filter out destructive mutation tools entirely. Does using Atlassian MCP cost extra? The Atlassian MCP server itself is provided without additional licensing fees for Atlassian Cloud customers, but invocations consume standard Cloud API rate limits or shared Atlassian Rovo credits. Furthermore, organizations pay their respective AI model providers (such as Anthropic or OpenAI) for the input and output tokens consumed during tool execution. How does Bifrost Edge secure local MCP setups? Bifrost Edge runs as a native endpoint agent on developer machines, continuously inventorying configured MCP servers in tools like Claude Desktop and Cursor. It intercepts local AI traffic and routes it through the Bifrost gateway, applying central virtual keys, guardrails, and audit logging to endpoint AI without requiring developers to change their local configurations. Next Steps for Enterprise MCP Adoption Deploying Model Context Protocol integrations transforms static enterprise knowledge into actionable context for modern AI workflows. However, connecting autonomous agents directly to Jira and Confluence requires strong guardrails, granular tool filtering, and centralized visibility to protect proprietary intellectual property. Engineering leaders evaluating AI infrastructure can request a Bifrost demo to observe centralized MCP governance in action, explore the Bifrost GitHub repository, or review the comprehensive Bifrost MCP documentation to start governing enterprise tools today. Sources - Atlassian MCP Documentation & Overview - Anthropic: Introducing Atlassian's Remote Model Context Protocol Server - Official Atlassian MCP Server GitHub Repository - Model Context Protocol Specification by Anthropic

Beyond MCP: Wiring Your AI Coding Agent to Jira and Bitbucket with Atlassian's TWG CLI A CLI-first way to give your coding agent the ticket, the PR, and the review comments. Why it usually costs fewer tokens than an MCP server, and what broke when I set it up on a corporate Windows laptop. By Adeyemi Tubosun · October 2026 · 10 min read The problem: your agent can write code, but it can't see the ticket. AI coding agents are now good at writing code. Most of them are still blind to why the code is being written. The acceptance criteria live in Jira, the design notes live in Confluence, and the review comments live in a Bitbucket pull request. So developers become the copy-paste layer between their tools and their agent. I hit this as a new engineer joining a team that runs on Jira and Bitbucket. Every ticket meant the same loop: open Jira, copy the story into the chat, write code, switch to Bitbucket, write a PR description by hand, then switch again to read and answer review comments. This article shows how Atlassian's Teamwork Graph CLI (TWG CLI) closes that loop, why its CLI-first design suits coding agents better than a typical Model Context Protocol (MCP) server, and what I learned setting it up on a locked-down corporate Windows machine. What TWG CLI is TWG CLI is a command-line tool that gives AI coding agents access to your Atlassian work context. Atlassian describes it as built for agents first, not retrofitted for them (Atlassian Support). It sits on top of the Teamwork Graph, Atlassian's map of people, content, activity, and the relationships between them. The graph is permission-aware, so the agent only sees what you can already see (Atlassian Developer). What it covers: - Jira: work items, boards, sprints, filters, transitions, and links - Confluence: pages, spaces, databases, whiteboards, and search - Bitbucket: repositories, pull requests, branches, commits, and pipelines - Also: Jira Service Management, Assets, Loom, Trello, Rovo Search, and Goals It works with Claude Code, Codex, Gemini CLI, Cursor, and other agents that can run shell commands. You never learn its syntax. You ask for an outcome, such as "What are my open Jira issues?" and the agent picks the commands (Atlassian Developer). At the time of writing, TWG CLI is in Atlassian's Early Access Program and free to use, with a note that some features may become paid later (Atlassian Support). Why not just use MCP? The context tax MCP is an open protocol that lets an agent discover and call external tools through a standard interface. Atlassian ships its own: the Rovo MCP Server, a cloud-hosted endpoint for Jira, Confluence, Jira Service Management, Bitbucket, and Compass, secured with OAuth 2.1 and your existing permissions (Atlassian Developer). It is a good product. The question is which shape fits a coding agent. The main cost of MCP for coding agents is context. A typical MCP client loads every tool's name, description, and input schema into the model's context window up front, before the agent does any work (MindStudio). Large servers make this expensive. One widely cited example is a GitHub MCP server adding roughly 55,000 tokens of definitions before the first task (Manveer Chawla). Benchmarks reported by Tyk put MCP at 4 to 32 times the tokens of equivalent CLI calls (Tyk). A CLI works the other way round. The agent starts with almost nothing loaded. When it needs a command, it runs --help for that command and reads a few hundred tokens. TWG leans into this: every command follows the same patterns and exposes help at every level, so the agent can discover features as it goes (Atlassian Support). To be fair to MCP, clients are getting smarter. Claude Code, for example, added tool search so it no longer loads every schema at once (VideoGen). The gap is narrowing, but for a coding agent that already lives in a terminal, a CLI is still the more natural fit. TWG CLI vs. the Rovo MCP Server at a glance Both respect your Atlassian permissions. They differ mainly in where they run and how they load into the agent. | | TWG CLI | Rovo MCP Server | | --- | --- | --- | | Runs on | Your machine, as a local binary | Atlassian's cloud, as a remote endpoint | | Context cost | Help is read on demand, per command | Tool schemas load up front, unless the client supports tool search | | Sign-in | Browser OAuth, plus a Bitbucket API token for PR features | OAuth 2.1; Bitbucket and Jira Service Management tools need API token auth | | Products | Jira, Confluence, Bitbucket, Jira Service Management, Assets, Loom, Trello, Rovo, Goals | Jira, Confluence, Jira Service Management, Bitbucket, Compass | | Composability | Output can be piped into scripts and other shell commands | Calls go through the MCP client | | Best fit | Coding agents in a terminal or IDE | Browser and chat clients without a shell | | Status | Early Access, free for now | Generally available for Jira, Confluence, and Compass | Sources: TWG CLI docs, Rovo MCP docs, Rovo MCP on GitHub. Token consumption: what changes when TWG is added Adding TWG barely changes the agent's starting context, while an MCP server adds its whole tool list to every session. The exact gap depends on the server and the client, so treat the published figures below as a guide and measure your own setup. What published measurements show | Setup | Tokens loaded before the first task | Tokens for a typical task | Source | | --- | --- | --- | --- | | GitHub MCP server (43 tools) | About 55,000 | Schemas stay loaded all session | Manveer Chawla | | MCP server with 20 tools | 3,000 to 10,000 | Schemas stay loaded all session | MindStudio | | Equivalent CLI (gh issue create) | Close to zero | About 200 tokens of help, under 500 in total | Manveer Chawla | Across equivalent tasks, Scalekit's benchmarks found MCP used 4 to 32 times the tokens of CLI calls (Tyk). These figures are not specific to Atlassian, but they show the pattern. Where TWG sits TWG reaches Claude Code as skills plus a CLI. A skill loads only its short name and description at the start of a session; its full instructions load when the agent decides to use it. The agent then reads TWG's command help only for the command it is about to run. So the fixed cost is a few short skill descriptions, and the rest is paid per task, in proportion to what the task needs. In short, a TWG workflow generally uses fewer tokens than the same workflow over MCP. The saving is in overhead: an MCP server keeps all of its tool definitions in context for the whole session, used or not, while TWG loads only what the current step needs. > Two caveats > > - The content costs the same either way. A long Jira description or a large PR diff takes the same tokens whether it arrives through MCP or TWG. If a task is mostly reading big tickets or diffs, the difference shrinks. > - The gap is narrowing. MCP clients are adding tool search, which loads tool definitions only when needed. Claude Code already does this (VideoGen), and it removes much of MCP's up-front overhead. Measure it yourself Run the same prompt in three fresh sessions and record the numbers. In Claude Code, /context shows how the context window is split, including tool definitions. 1. Start a session with no Atlassian integration and run /context. This is your baseline. 2. Add the Rovo MCP Server, start a new session, and run /context it again. Then ask, "Fetch PROJ-1234 and summarize its acceptance criteria," and run /context it once more. 3. Remove the MCP server, enable TWG, and repeat step 2 in a new session. | Setup | Tool and skill definitions at start (tokens) | Total after the fetch-and-summarize task (tokens) | | --- | --- | --- | | Baseline, no integration | [your number] | [your number] | | With Rovo MCP Server | [your number] | [your number] | | With TWG CLI | [your number] | [your number] | Your own numbers will make this section far more convincing than any benchmark. If your client supports tool search for MCP, note that too, since it narrows the gap. Five workflows that change day to day Once TWG is connected, you stop moving text between tools and start asking for outcomes. These are the workflows that made the biggest difference for me. 1. Pick up a ticket. "Pick up PROJ-1234." The agent reads the story and its acceptance criteria, creates a branch, and proposes a plan. You start from the real requirements, not your memory of them. 2. Open a pull request in one step. "Commit, push, and open a PR for PROJ-1234." The agent writes the PR description from the ticket and the diff, so descriptions stay consistent and linked to the work item. 3. Address review feedback without the browser. "Address the comments on my PR." The agent pulls the reviewer's notes, makes the fixes, and drafts replies for you to check. 4. Review against the ticket, not only the code. "Review PR #193." The agent checks the diff against the acceptance criteria, which catches the "clean code, wrong feature" problem a style-only review misses. 5. Get a morning view. "What's on my plate?" The agent combines your sprint tickets with the PRs waiting on your review. It makes a good starting point for stand-up. The common thread is that the agent works from the same source of truth as your team. That matters more than speed. A PR description generated from the ticket is more accurate than one typed from memory at 6 p.m. Setting it up, including the corporate-network gotchas The official setup takes about ten minutes. On a corporate Windows laptop, it took me longer, so here is the path that worked plus the problems you are likely to hit. 1. Install the binary On Windows, Atlassian's installer is a PowerShell script (TWG CLI on GitHub): curl.exe -fsSL https://teamwork-graph.atlassian.com/cli/install.ps1 -o "$env:TEMP\twg-install.ps1" powershell -ExecutionPolicy Bypass -File "$env:TEMP\twg-install.ps1" -Yes -SkipLogin -Plugin claude-code > Run this yourself. Agents running in an automatic mode will usually refuse to download and execute a remote script, and they are right to. 2. Open a new terminal The installer adds TWG to your user PATH, but the current window will not see it. Check with twg --version. 3. Connect your account and your agent twg setup twg skills install --agent claude twg upkeep enable twg setup runs a browser login and asks for your Atlassian site. Say yes when it offers a Bitbucket API token, or the PR features will not work. Paste the token only into TWG's masked prompt, never into a chat. The second command puts TWG's skills where Claude Code looks for them. The third keeps your login refreshed in the background. 4. Verify Start a new agent session and ask it to run twg doctor and fetch a ticket you know. Every check should pass. Gotchas I hit - The installer hangs while downloading the binary. Corporate HTTPS inspection can slow or stall large downloads. Download the binary directly with curl.exe into %LOCALAPPDATA%\Programs\twg\bin\twg.exe, add that folder to your user PATH and continue from step 2. This skips the installer's plugin step, so do not skip twg skills install. - Node scripts fail with unable to get local issuer certificate. The same HTTPS inspection breaks Node tools that call Atlassian's APIs. Recent Node versions can trust the Windows certificate store with --use-system-ca. On older versions, export the trusted roots to a PEM file and point NODE_EXTRA_CA_CERTS at it. Never set NODE_TLS_REJECT_UNAUTHORIZED=0, which switches off certificate checks entirely. Guardrails: the agent acts as you Anything the agent posts appears under your name: PRs, comments, ticket transitions. Treat that seriously. - Approve every write. Let the agent read freely, but confirm each PR, comment and status change before it goes out. - Own the output. A generated PR description or review reply is a draft. Read it as if you wrote it, because your name says you did. - Keep secrets out of chats and repos. Tokens belong in masked prompts, OS credential stores or git-ignored .env files. Check with git check-ignore .env before you add one. - Know which account is active. On a machine with both personal and company AI accounts, confirm the active one before working on company code, and follow your employer's policy on personal tools. - Least privilege still applies. TWG and the Rovo MCP Server both inherit your Atlassian permissions. They never grant more, so an over-privileged user means an over-privileged agent. When MCP is still the better choice A CLI-first tool is not a universal winner. Pick the Rovo MCP Server when: - Your client has no shell. Browser-based agents and chat apps cannot run a local binary. Atlassian's own plugin listing tells people using Claude Code in the browser to install the Rovo MCP plugin instead (Claude plugins). - Non-developers need access. Product managers and support staff can connect a hosted MCP server without installing anything. - Admins want central control. Atlassian administrators can control which external AI tools and domains may connect to the Rovo MCP Server (Rovo MCP on GitHub). Many teams will run both: TWG CLI for developers in the terminal, and Rovo MCP for everyone else. Key takeaways - Coding agents are only as good as the context they work from. Connecting them to your tickets and PRs matters more than a better prompt. - For agents that live in a terminal, a CLI like TWG keeps the context window lean by reading help on demand instead of loading every tool schema up front. - MCP still wins for browser clients, non-developers and centrally managed access, so most teams will use both. - On corporate machines, expect network and certificate friction. Fix it with the system certificate store, not by disabling TLS checks. - The agent posts as you. Approve every write, and treat its output as your own draft. Sources - What is Teamwork Graph CLI? (Atlassian Support) - Teamwork Graph CLI (Atlassian Developer) - TWG CLI (Atlassian Developer) - atlassian/twg-cli (GitHub) - Atlassian Teamwork Graph CLI plugin (Claude plugins) - About the Atlassian Rovo MCP Server (Atlassian Developer) - atlassian/atlassian-mcp-server (GitHub) - MCP vs CLI for AI agents: enterprise comparison guide (Tyk) - MCP vs. CLI for AI agents: when to use each (Manveer Chawla) - MCP vs CLI for AI agents: token costs (MindStudio) - CLI vs MCP: what AI agents actually use now (VideoGen)

I do not understand how @Atlassian @Jira can keep this kind of business critical infosec issue not fixed more than half a year, and still call themselves "AI Native". MCP lies to agent about sending internal note, server errors and posts exernal comment atlassian-mcp-server#139

5️⃣ Atlassian MCP: the ticket is the spec 🔗 atlassian/atlassian-mcp-server ↳ Scope cuts and edge cases live in the Jira comments and rarely reach the description. ↳ An agent that reads only the description builds last week's version of the feature.