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.

[Gabriela - LeanZero]

Hi @Bryun Sakaye, that v2 preview result settles the client question I left open, assuming you ran both from the same Claude Code install. One setup, two endpoints, mcp.atlassian.com/v1/mcp/preview and /v1/mcp, and only v1 truncates, so it isn't MAX_MCP_OUTPUT_TOKENS and it isn't anything else client side. That pair's a shorter read for whoever picks this up than any repro of the pipeline.

[Suyash Kumar Tiwari]

Hey @Bryun Sakaye - We will look into this and get back with an appropriate fix. Thanks for bringing this up. 

[Teja Tarigopula]

Any update on this issue? i am also facing similar truncation issue, since last week.

[Bryun Sakaye]

I was able to get around the issue by connecting to the MCP v2 preview version. https://community.atlassian.com/forums/Atlassian-Remote-MCP-Server/Preview-Atlassian-Rovo-MCP-v2/ba-p/3255431

[Michael Silva]

Interesting, @Bryun Sakaye - the workaround didn't work for me. I guess I'll wait on this one. 

[Teja Tarigopula]

I'm using connector provided by my company. I cannot upgrade to a different version. 

[Michael Silva]

I'm seeing the same issue. My queries worked fine on 14-Aug-2026.

[Michael Silva]

I tried the workaround to use the preview, and it didn't work. 
I also tried to just return many sets of batches of 5, but that was not working for me (paging token was expiring midway through)

[Michael Silva]

This is fully fixed now. 

[jmcmunn]

Wasted way too much time today wondering why my Claude skill started reporting bad numbers...found this bug as well.  ETA on a prod fix here?  This one sucks.

[Madhu Gupta]

I have set up an integration with the Atlassian Rovo MCP Server using Claude Managed Agents, and I am facing the same pagination issue with the searchJiraIssuesUsingJql tool.

The agent invokes the tool with the following request:

{
  "cloudId": "<your_atlassian_cloud_id>",
  "fields": [
    "key",
    "summary",
    "priority",
    "attachment",
    "created",
    "customfield_12053"
  ],
  "jql": "<JQL_query>",
  "maxResults": 50
}

However, even when the JQL query matches more than 50 issues, the tool returns only 5 issues, along with:

{
  "hasNextPage": false,
  "endCursor": null
}

and:

"remainingCount": 4

This makes it impossible for the agent to determine that additional Jira issues exist or to paginate through the remaining results.

I understand that Atlassian Rovo MCP has pagination support in newer versions, but I cannot move to the Rovo V2/Preview endpoint (https://mcp.atlassian.com/v1/mcp/preview) because Claude Managed Agents currently supports only the Rovo V1 endpoint (https://mcp.atlassian.com/v1/mcp).

This appears to be a limitation/issue in the V1 searchJiraIssuesUsingJql implementation. There is also an existing Atlassian MCP issue reporting similar pagination problems with this tool, where pagination metadata is missing and agents cannot reliably retrieve results beyond the first page.

As a result, my workflow is currently blocked. I cannot use the existing V1 integration to reliably fetch all Jira tickets matching a JQL query, and I cannot switch to the newer Rovo endpoint because of the Claude Managed Agents compatibility limitation.

At this point, I don't see a viable workaround that satisfies all of these constraints.

[Andrea Frehner]

Confirming this is still an issue for us as of today (Aug 19, 2026).

Repro example: project = SIC24INT AND statusCategory != Done (12 issues total) returns only 5 nodes in issues.nodes, with remainingCount: 7 and pageInfo.hasNextPage: false — no cursor available to retrieve the rest. Same behavior regardless of maxResults (tested 50 and 100). The ORDER BY key ASC + manual key > "<last-key>" cursor workaround does work to advance through results, but each call is still capped at 5 results.

Also worth flagging: the fields parameter appears to be ignored entirely — even when requesting only ["summary","status"], the response includes the full issue payload (including the complete description), which makes large-scale rebuilds across many projects very expensive.

This was working correctly for us until at least Aug 14, so this looks like a regression rather than a pre-existing limitation — matches what's already reported here.

Side note: the AI assistant on the Atlassian support portal referenced two different "ECO-" ticket numbers for this issue (ECO-1498, then ECO-1398) when asked for a tracking reference — neither corresponds to this issue when checked directly (both are unrelated, unrelated feature requests). Might be worth a look separately, since it could mislead other customers trying to track this.

[Suyash Kumar Tiwari]

Quick update: we've shipped a fix for this in MCP v1 endpoint as well. The searchJiraIssuesUsingJql tool will now return the full page of results with a correct nextPageToken, so you can page through large result sets reliably instead of stopping at ~5 issues.

It's merged and rolling out now. Expect it to reach all users over the next day or so as the deployment completes, no action needed on your end.

If you still see truncated results after that, reply here with your MCP client and roughly when you ran it and we'll take another look. Thanks for the clear report that helped us pin this down. 🙏

[Andrea Frehner]

@Suyash Kumar Tiwari 

Follow-up on the pagination fix (20 Aug): the truncation itself is still there, just the symptom changed

Thanks for the fix, the missing cursor for ≤100-result queries is indeed resolved now. However, after retesting right after the rollout, there's a second, deeper bug that was previously masked by the missing-cursor issue and is now clearly reproducible:

Each page internally advances by the full requested maxResults, but only the first 5 issues of that internal batch are ever returned in nodes. The other maxResults - 5 issues in that batch are silently dropped and never appear on any subsequent page, since the cursor has already skipped past them.

Test 1 — project = SIC24INT ORDER BY key ASC, maxResults: 10:
- Page 1: returns keys SIC24INT-1 to -5, remainingCount: 5
- Page 2 (using the returned nextPageToken): jumps straight to SIC24INT-11 to -15, remainingCount: 5
- SIC24INT-6 through -10 (5 issues) never appear in any response.

Test 2 — same JQL, maxResults: 50:
- Page 1: returns keys SIC24INT-1 to -5, remainingCount: 45
- Page 2: jumps to SIC24INT-53 to -57, remainingCount: 24 - SIC24INT-6 through -52 (44 issues, project has a spear.

In both cases: remainingCount = maxResults - 5, not the true remaining count in the full result set, and the cursor advances by maxResults, not by the 5 issues actually surfaced. Ss value we send, we only ever get 5 real results percall, and every page permanently loses maxResults - 5 issues that are never recoverable through pagination.

Could you confirm whether the 5-issue cap is an intedownstream, and if so, either return all maxResultsissues in nodes, or at minimum advance the cursor by 5 (the number actually returned) so no issues are silently lost? Happy to share the full raw responses if useful for repro.

MCP client / timing: Atlassian Remote MCP Server (v1:streamable-http, env: prod), accessed through Claude (clientName: claude.ai). Both tests above were run on 2026-08-20 at roughly 17:40 CEST (UTC+2), i.e. a few hours after your fix rollout announcement earlier the same day.

[Suyash Kumar Tiwari]

Hey Andrea - The fix has completed deployment now. Can you please check again and confirm if the problem persists?

[Andrea Frehner]

Hello @Suyash Kumar Tiwari 

Thanks for the fix — I can confirm it's working now.

Re-ran both of my earlier reproduction cases (project = SIC24INT ORDER BY key ASC):

- maxResults: 10 → returns all 10 issues (SIC24INT-1 through -10), no gap. Previously only 5 came back.
- Cursor pagination via nextPageToken → next page correctly returns SIC24INT-11 through -20, no missing issues.
- maxResults: 50 → returns all 50 requested issues (SIC24INT-1 through -52, accounting for two keys that legitimately don't exist), instead of the previous 5.

The truncation/lost-batch issue is resolved for me. Thanks for the quick turnaround.

One remaining issue I noticed (separate from the pagination bug, but already a real problem on its own): the fields parameter still appears to be ignored — even when requesting only ["summary"], the response includes the full issue payload (description, status, avatars, etc.) for every issue. This is already quite inefficient on its own: a maxResults: 50 call for just summaries came back as 130k+ characters, which is wasteful for both the API and the client parsing it, and it's the main thing standing between me and being able to do a full project rebuild efficiently now that pagination itself is fixed.

Is this being tracked, and do you have any visibility into when a fix for that might land?

[Bryun Sakaye]

Hi @Suyash Kumar Tiwari

Re-tested today (2026-08-22) on the stock MCP endpoint against our Jira Cloud
site, tool searchJiraIssuesUsingJql. Two of the three problems are gone.

FIXED, result cap.
maxResults: 50 now returns 50 issues. Before, it returned 5 no matter what
I asked for.

FIXED, pagination.
pageInfo.endCursor is populated on a large-page call. Passing it back as
nextPageToken returned a second page of 50 with zero overlap against page
one. Before, a large-page call returned hasNextPage: false and a null
cursor, so the call could not be resumed and looked complete.

STILL BROKEN, the fields parameter is ignored.
Request: jql "project = ESP ORDER BY created DESC", maxResults 50,
fields ["status"]
Expected: status only
Actual: assignee, description, issuetype, project, status, summary
on every issue

Same result with fields ["key","status"]. The full description body comes
back either way, so a 50-issue page is roughly 250 KB and exceeds the
response budget of any MCP client. There is no way to narrow a response
right now.

This is the one that still costs us. We read across about 150 issues and
need a few fields, so being forced to pull every description turns one
cheap call into an unusable one. The v2 preview endpoint does honor fields
(at view: "full"), so we are using that for bulk reads.

I can re-test whenever you have a build.

[Gabriela - LeanZero]

Andrea, on the tracking question. That symptom has its own ticket, JRACLOUD-98814, and its Actual Results name the exact six fields Bryun got back, summary, issuetype, project, description, assignee, status, with the ticket's own wording being that they are always returned and cannot be stripped from the response. It went to Waiting for Release on 13 Aug and closed as Fixed on 17 Aug, with a comment saying the fix had been completely rolled out. Your 19 Aug run and Bryun's re-test on the 22nd both land after that.

The same report was then filed again as JRACLOUD-99274 on 21 Aug, same description, and it sits at Needs Triage, unresolved. So it is tracked on a live id rather than closed against your measurements. Two watchers and no votes right now, no comments, and no public ETA.

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