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.
- Start a session with no Atlassian integration and run
/context. This is your baseline. - 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. - 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.
- 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.
- 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.
- 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.
- 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.
- 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.exeinto%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 skiptwg 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 pointNODE_EXTRA_CA_CERTSat it. Never setNODE_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
.envfiles. Check withgit check-ignore .envbefore 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)
Top comments (0)