Holy Burning Tokens, Batman! or how Atlassian’s Rovio MCP eats tokens for breakfast.

I’ve been building a workflow where Claude maintains project documentation and wanted to create Jira tickets automatically when milestones are hit. The project is running in Claude Code, the codebase context is already there, and I have a Markdown test plan document that has been maintained throughout the build. After a couple of rounds of testing, it became clear that using a text document was not the right way to do this, so I wanted to get Claude create the corresponding Jira tickets directly.

I connected up the official Atlassian Rovo MCP connector and asked Claude to read the test document and create the tickets.

It spun up 23 parallel agents and consumed 612k tokens in five minutes to create 23 tickets in Jira. I was sitting there watching the token usage, and it just kept going up and up at a rapid pace.

Claude did what I asked it to. The tickets were created, structured properly, and it would have taken me over half an hour to do all this manually. But over half a million tokens for 23 tickets is a crazy level of usage, so I wanted to find out why.

I asked Claude what happened, and how it managed to burn so many tokens. The answer was pretty ystraightforward:

The Atlassian Rovo MCP server exposes 33-plus tools, each with verbose JSON Schema definitions. That full manifest is injected into context on every single API call — there’s no caching between calls. On top of that, Claude Code maintains full conversation history across all tool calls, so by ticket 23 you’ve got the manifest plus the accumulated input and output of the previous 22 operations sitting in context. Token cost grows roughly quadratically if you run sequentially. Each createJiraIssue response also returns the full issue object — rendered ADF content, all field metadata, the interactive UI render payload — somewhere between 2,000 and 5,000 tokens per response. And if Claude is calling getAccessibleAtlassianResources to resolve the cloudId before each ticket rather than caching it, that’s an additional full-manifest round-trip per ticket on top of everything else.

Fortunately for me (and my rapidly dwindling token budget) Claude was smart enough to parallelise across 23 agents, which at least avoided the quadratic history growth and completed the task significantly faster. If the workflow had have been performed sequentially, it likely would have consumed anywhere from 2M to maybe 10M tokens. So the parallelisation definitely saved tokens and time.

I still needed to do more tickets in Jira, so I noped right out of that approach and had Claude write a Node.js script to talk directly to the Jira API.

I then encountered another difficulty: the Jira API scope system is a real mess. Something like 380 granular scopes with no sensible grouping — there’s no “Create Ticket” permission, you have to know exactly which combination of low-level scopes covers your use case. I tried several permutations and couldn’t get it working reliably, so I fell back to a Classic API key (i.e. access all areas) for this project.

Once that was sorted, Claude wrote a script that read the test document and the test notes, searched for, read and edited the 23 tickets, organised them into epics, applied tags, and transitioned the relevant ticket statuses. Total token cost: less than 6,000 tokens.

6k vs 600k tokens. I’m pretty sure I know which way I’ll be doing it in the future.

The MCP connector might be the right tool when you’re having a conversation and you want to do a single task in Jira, interactively, without leaving the chat. That context with the manifest overhead, the verbose responses, and the full history may be a reasonable price for that convenience but you’re still looking at maybe 20k – 25k tokens for a single ticket. The moment you’re doing bulk operations, anything that loops or works in batches, the Rovo MCP is absolutely the wrong tool. It’s simply not fit to be used for an automated workflow.

For bulk Jira operations: write a script (or use mine). Claude can write it for you in a hot minute, and the token cost of generating the script is and then running it is less than creating a single ticket via MCP. I’ve now got a straightforward and sustainable way for Claude to create Jira tickets whenever a chunk of work is completed and documented.