Remote MCP Server: getJiraIssue returns only the oldest 20 worklogs (no pagination or date filter)

[Todd Joyce]

Has anyone else run into the worklog read limit on the Atlassian Remote MCP Server, and is it already logged with Atlassian?

The behavior

On Jira Cloud via mcp.atlassian.com, getJiraIssue returns only the oldest 20 worklogs per issue. It reports worklog.total correctly (we have issues showing 4,000+), but returns 20 entries with:

• no pagination (startAt / maxResults)
• no date filter (startedAfter / startedBefore)

There also doesn't appear to be a dedicated worklog tool exposing GET /rest/api/3/issue/{key}/worklog, which supports all of those parameters in the REST API. Requesting fields: ["worklog"] on the JQL search tool returns the same oldest-20 page. The fetch tool only accepts ARIs, so the REST endpoint isn't reachable that way either.

Why it's worse than a simple cap

The failure is silent. If you sum the visible 20 worklogs per issue to build a monthly report, you get a number that looks clean and is wrong.

In our case, month-level totals came out ~21% under the true figure, and several issues reported zero hours for the month while genuinely having time logged in it — because their entire month sat in the truncated portion. Nothing errors, so there's no signal that you're missing data.

Anyone doing "batch the pulls and aggregate" to work around response size limits will hit this and not notice.

Two related things we hit while working around it

1. The JQL search tool returns only 5 issues per response, and pageInfo.endCursor comes back null with hasNextPage: false even when remainingCount is 40+. Enumerating ~50 issues took ~30 queries.
2. JQL key range comparisons return 0 instead of erroring. key >= PROJ-1 returned nothing against a known 47-issue result set, and a two-sided range returned 0 while a strict subset of that same range returned 34. Exact key = X works fine. This silently corrupts results if you partition a large pull by key range — which is a natural thing to try given #1.

Partial workaround, in case it helps anyone

The changelog is not subject to the 20-entry cap:

getJiraIssue(issueIdOrKey: "PROJ-123", fields: ["timespent"], expand: "changelog")

Changelog items include WorklogId, WorklogTimeSpent, and timespent from/to cumulative values. Replaying the deltas recovers every worklog's ID and exact amount, including deleted ones — it reconciled to the second against lifetime timespent on every issue we tested.

The catch: changelog timestamps are when a worklog was recorded, not the date it was worked. To bridge that we combined it with:

• per-day worklogDate = "YYYY-MM-DD" JQL probes, which reveal exactly which calendar days have worklogs
• worklogAuthor probes to discriminate between logging identities on a given day
• the fact that the returned worklog list is sorted by started ascending, so hidden entries are always the latest-started ones

Where the number of days equals the number of hidden entries, the mapping is forced and the result is exact. That resolved most issues exactly, with the rest inside a narrow band.

It works, but it's ~230 tool calls for one project, one month, one account dimension. Not something to run monthly.

Questions

1. Has anyone else hit the 20-worklog cap? Curious whether it's universal or config-dependent.
2. Is there an existing Atlassian ticket for worklog pagination on the MCP server? Didn't want to file a duplicate.
3. Same for the 5-issue search cap / broken pagination cursor, and the key-range JQL behavior — worth separate tickets, or known issues?
4. For those doing time reporting through Tempo: are you going direct to the Tempo API instead? There's no Tempo MCP connector that we can find, and Tempo returns worklogs with dates and accounts in a single paginated call, which would make all of the above moot.

Happy to share the reconstruction approach in more detail if it's useful to anyone.

[Gabriela - LeanZero]

It's logged, @Todd. ECO-1431, a Suggestion on the API - Model Context Protocol component, at Gathering Interest with one vote, two watchers and no comments. Filed 10 April, and the last change to it landed 87 seconds later. Gathering Interest means it needs more unique domain votes and comments before Atlassian reviews it, so your 21% and the 4,000-worklog issues are the sort of thing that moves it. Others have hit it as well. GitHub atlassian/atlassian-mcp-server issue 180 has been open since 18 June with no comments and three thumbs up, and it names the same endpoint no tool wraps.

If you comment on it, push the second half of the request rather than the first. ECO-1431 asks for pagination on the fields the tools return, and failing that "build a specific tool to return work logs that support pagination". The first ask has a long refusal behind it. JRACLOUD-34746, 39 votes, closed as Answered on 12 April 2017, Cezary Zawadka's closing comment reading "as it was made due to performance reasons we want to keep it as it is", with a pointer to the dedicated worklog endpoint instead. The alternative is the route Atlassian's own answer sent people down, and it's what 180 asks for.

The 5-issue search cap is a known one: searchJiraIssuesUsingJql truncates to 5 issues and drops the pagination cursor. Suyash Kumar Tiwari shipped a fix there on 20 August, merged and rolling out, reaching everyone "over the next day or so". It isn't fully closed. Andrea Frehner retested at 17:40 CEST that same day, v1 streamable-http against prod, and reports the cursor is fixed while the cap is not: a page still returns 5 issues, but the cursor advances by the full maxResults, so each page skips the maxResults minus 5 it didn't hand back, and the retest didn't see those again on any later page. Nothing errors there either. I'd check remainingCount against the true remainder before trusting a paged pull. On the key-range one I have nothing useful.

I can't tell from your post whether that's v1 or the v2 preview, and it mattered on the search bug, so take the above as v1 as of today.

[Todd Joyce]

thank you @Gabriela - LeanZero !

[Gabriela - LeanZero]

There is a worklog read operation. It isn't on the endpoint you're using. The v1 tool list carries one worklog entry and it's addWorklogToJiraIssue, a write. The preview endpoint, mcp.atlassian.com/v1/mcp/preview, lists getIssueWorklog, "List worklogs for a Jira issue to read entries and discover worklog IDs for edits or deletes". It won't appear in tools/list. You find it with discover and call it with execute.

I can't tell you whether it paginates. That page documents no parameters for it at all, and the purpose it states is finding IDs to edit and delete. Atlassian also says which discovery operations you can see depends on your scopes and toolsets, so it may not even be there for you. Probe it before you plan around it.

The 5-issue half of what I told you has aged out, and so has the caution I gave with it. Suyash posted at 20:41 PDT on the 20th that deployment had completed. Andrea Frehner retested at 22:04 that night, maxResults 50 returning all fifty, and called it resolved. Michael Silva came back with one line, fully fixed. Bryun Sakaye retested on the 22nd on a different site, and that one covers the shape you described. A large-page call used to come back hasNextPage false with a null cursor and look complete. Now the cursor is populated, and passing it back returned a second page of fifty with no overlap. So drop what I said about checking remainingCount before trusting a paged pull. The ticket is JRACLOUD-99221, closed as Fixed at 20:21 PDT, twenty minutes before Suyash posted.

ECO-1431 also moved since I quoted it. Three votes, three watchers and one comment now. The comment is yours.