getMissingWorklogDays is the reason to install this rather than call the Tempo API directly: it reads the user-schedule, drops holidays and non-working days, and returns the shortfall per day with a per-issue breakdown for the days that are partly filled — the part a raw worklog export never gives you. Using it across a team is a permissions question rather than a tooling one, since the user, program and team filters all depend on what the token owner's Permission Role allows. Bulk exists only on creation: edits and deletions are one worklog ID at a time.
A server over the Tempo worklog API with Jira alongside it — worklogs retrieved, created, edited and deleted, plus schedule-aware gap detection and grouped analytics.
- Worklogs for a date range, defaulting to the token owner's own and widening to other people through user, program or team filters that combine as a union
- Entries written one at a time or as an array in a single bulk call, then edited or deleted by worklog ID
- getMissingWorklogDays, which compares logged hours against the expected hours in the Tempo user-schedule, skips holidays and non-working days, and returns expected against logged with a per-issue breakdown for partially logged days
- getWorklogAnalytics, grouping hours, worklog count and percentage by issue, account, user, day, ISO 8601 week or month, sorted by hours
TEMPO_API_TOKEN, JIRA_API_TOKEN, JIRA_EMAIL and JIRA_BASE_URL. Reading anyone else's worklogs needs a Tempo Permission Role carrying 'View Worklogs'; getMissingWorklogDays additionally needs the 'Schemes' scope on the Tempo token. MIT.
One command plus a key — npx -y @ivelin-web/tempo-mcp-server, then supply credentials