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
- 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.
- 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
- Has anyone else hit the 20-worklog cap? Curious whether it's universal or config-dependent.
- Is there an existing Atlassian ticket for worklog pagination on the MCP server? Didn't want to file a duplicate.
- Same for the 5-issue search cap / broken pagination cursor, and the key-range JQL behavior — worth separate tickets, or known issues?
- 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.
