Tempo Timesheet MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Log level: debug | info | warn | error. | info |
| JIRA_EMAIL | No | Atlassian account email (optional). Must be set together with JIRA_BASE_URL and JIRA_API_TOKEN. | |
| JIRA_BASE_URL | No | Jira Cloud base URL, e.g. https://<site>.atlassian.net (optional). Must be set together with JIRA_EMAIL and JIRA_API_TOKEN. | |
| JIRA_API_TOKEN | No | Atlassian API token (optional). Must be set together with JIRA_BASE_URL and JIRA_EMAIL. | |
| TEMPO_BASE_URL | No | Tempo v4 base URL. | https://api.tempo.io |
| TEMPO_API_TOKEN | Yes | Tempo API token (required). | |
| DEFAULT_TIMEZONE | No | IANA timezone name, e.g. Asia/Ho_Chi_Minh. Defaults to the system timezone. | |
| WORKLOG_WRITE_ENABLED | No | Master switch for write tools. Writes are gated by this flag, a payload-bound approval token, and confirm: true. | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| tempo_get_worklogsA | Retrieve Tempo worklogs recorded within an inclusive date range (YYYY-MM-DD). Optionally scope to one Jira accountId. Read-only; requires TEMPO_API_TOKEN. |
| tempo_get_worklogB | Retrieve a single Tempo worklog by its tempoWorklogId. Read-only; requires TEMPO_API_TOKEN. |
| jira_search_issuesA | Search Jira issues. Provide either a jql string, or projectKey and/or text (combined with AND). Read-only; requires JIRA_BASE_URL, JIRA_EMAIL and JIRA_API_TOKEN. |
| tempo_get_week_summaryA | Aggregate RECORDED Tempo worklogs for one week (Monday..Sunday) by day and by issue. The week is resolved from |
| tempo_preview_worklogA | Prepare a proposed worklog for user review WITHOUT writing to Tempo. operation="create": pass proposal {issueKey, date, durationMinutes, description, startTime?}. operation="update": pass worklogId and changes {description?, timeSpentSeconds?, startDate?, startTime?}. Returns validation results, duplicates, and (when valid) an approvalToken required by the write tools. Show the full preview to the user and wait for explicit approval before calling a write tool. |
| tempo_validate_worklogA | Validate a proposed worklog: issue existence/access, date, duration, description, and timezone warnings. Returns validation errors and warnings. Does NOT write and does NOT approve anything. |
| tempo_check_duplicateA | Compare a proposed worklog against existing Tempo worklogs for the same issue and date. Returns possible matches with confidence (high/medium/low) and reasons. Heuristic only — it cannot guarantee uniqueness. Read-only. |
| tempo_create_worklogA | Create a Tempo worklog after explicit user approval. Requires: writes enabled (WORKLOG_WRITE_ENABLED=true), confirm=true, and an approvalToken obtained from tempo_preview_worklog for the EXACT same proposal. Refuses to run without all three. Verifies the created worklog afterwards and reports uncertain outcomes instead of retrying. |
| tempo_update_worklogA | Update an existing Tempo worklog after explicit user approval. Requires: writes enabled, confirm=true, and an approvalToken from tempo_preview_worklog (operation="update") for the EXACT same worklogId and changes. No worklog deletion exists in this MVP. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
The read tools (get_worklog, get_worklogs, get_week_summary) are clearly distinct, as are create vs update. However, tempo_preview_worklog is a superset of tempo_validate_worklog and tempo_check_duplicate (it returns validation results, duplicate matches, and the approval token), so three tools circle the same pre-write proposal and an agent can easily pick the wrong one or call validate/check_duplicate and then wrongly assume it is cleared to write.
All tools follow a uniform <service>_<verb>_<noun> snake_case pattern (tempo_get_worklog, tempo_create_worklog, jira_search_issues), with the prefix consistently denoting the backing system. Verb choice is predictable across the CRUD/preview lifecycle.
Nine tools is well within a healthy range and each maps to a concrete step: read (single/range/summary), lookup (jira search), pre-write safety (preview/validate/check_duplicate), and write (create/update). No obviously filler tools.
Create and update are covered with strong safety rails, and reads cover single, ranged, and aggregated views. The notable gap is deletion (explicitly absent in the MVP), and there is no tool to inspect an existing worklog's issue metadata or list a user's worklogs outside a date range, both of which limit recovery from mistakes.