searchJiraIssuesUsingJql truncates to 5 issues and drops the pagination cursor

[Bryun Sakaye]

Some context on how I'm using this, since I think it matters for why this bit me
the way it did.

I drive Jira from Claude Code through the Atlassian MCP server. One of the things I've built on top of it is a meeting pipeline that syncs our Jira project into a local cache before it processes anything — it pulls every active ticket plus everything closed in the last 30 days, writes them to disk, and works from that snapshot. It's been running fine for months. As of yesterday (Aug 11, 9PM PST) it stopped working, and it took me a few tries and a fresh pair of eyes to work out what actually changed.

The short version: a JQL search that returns more issues than fit in the response now comes back truncated to 5 nodes, and the pagination cursor comes back empty — so there's no way to ask for the rest.

What threw me is that asking for *fewer* is what makes pagination work. At 100 the server seems to build the page, cut it down to fit, and lose the cursor on the way out — so the response tells me there are 85 more issues and simultaneously tells me there is no next page. At 5 it pages normally and I can walk the whole result set.

A couple of other things I noticed while digging, in case they're related:

• Passing `fields: ["summary"]` doesn't raise the node count, so this reads like a
  node cap rather than a payload-size cutoff. A base set of fields (summary,
  issuetype, project, description, assignee, status) comes back regardless of what
  I ask for.
• Oversized responses used to get written out to a file I could read separately.
  That doesn't happen anymore — it truncates in place instead.

Honestly, the cap itself I could design around. The part that actually cost me is that the truncation is silent. Nothing in the response distinguishes "here's a partial result you can resume" from "here's a partial result you can never finish," so anything built on this will happily treat 5 of 90 tickets as the whole world. In my eyes that's the real bug — a response that can't be completed should say so.

Is anyone else running into this since the update, particularly through Claude Code or another MCP client? Mostly I want to know whether this is an intentional change I should be building around, or a regression that's going to get fixed.

[Gabriela - LeanZero]

Hi @Bryun Sakaye, nothing published says it is intentional. The Rovo MCP changelog has two entries in its entire history, 1 July and 27 April, and the supported tools page gives searchJiraIssuesUsingJql a one line description and a scope, no parameters and no limits. You are not the first to lose the cursor on this tool though. Issue 118 on atlassian/atlassian-mcp-server has it in March, Atlassian shipped a pageInfo fix on 4 June, the reporter came back the same day with "this still isn't working", and it was closed as completed eleven days later with a standing invitation to reopen it. Ryan Sanford reported the same loss on this board in March. Citing 118 and asking whether this is a regression of it will triage faster than a fresh report.

You have 5 working and 100 not. Walk 10, 20, 50 before you file and hand them the exact number the cursor goes empty at. Nobody can argue with that, and it tells you what to pin the pipeline to tonight.

MAX_MCP_OUTPUT_TOKENS will not settle the client question. The docs say it "applies to tools that don't declare their own limit" and that a tool setting anthropic/maxResultSizeChars uses that instead regardless of it, so raising it proves nothing if Atlassian added the annotation. The shape discriminates better. When the client cap bites it is loud, and Christoph Koehler's post on this board has the wording, response 29544 tokens exceeds maximum allowed tokens 25000. Yours came back silent and well formed with a count of 85 sitting in it. That contrast belongs in the report.

JRACLOUD-98814 is open and In Progress on the same call shape, so keep the fields test in but do not lean on it. Issue 208 measured what that one costs you, narrowing recovers about 20 percent of the payload and description is still 44 percent of what is left. That is roughly one node of resolution at your page size. It points at a node cap without settling it.

https://jira.atlassian.com/browse/JRACLOUD-98814

[Bryun Sakaye]

Hi @Gabriela - LeanZero, I've been using the MCP for months and have not experienced any issues like this until yesterday. I would normally be able to query all open/in-progress tickets and it would return 80+ at a time. My agent skill is designed to take that entire payload and drop it into a temp file to avoid dropping it into my agent's context window. It then is processed into a local cache file for the agent to work with.

One thing I did discover today is the preview version of MCP v2. That preview version doesn't not have the same 5 item limit as the live v1.