Tempo MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_EMAIL | No | Your Jira account email (required for basic auth) | |
| JIRA_BASE_URL | No | Your Jira instance URL (e.g., https://your-org.atlassian.net) | |
| JIRA_API_TOKEN | No | Your Jira API token | |
| JIRA_AUTH_TYPE | No | Optional: 'basic' (default) or 'bearer' for OAuth 2.0 tokens | basic |
| TEMPO_API_TOKEN | No | Your Tempo API token | |
| JIRA_TEMPO_ACCOUNT_CUSTOM_FIELD_ID | No | Optional: Custom field ID for Tempo accounts |
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 |
|---|---|
| retrieveWorklogsA | Retrieve Tempo worklogs in a date range. Defaults to the authenticated user's own worklogs. Optional filters fetch other users' worklogs instead: 'users' (emails, display names, or accountIds), 'program' / 'team' (all current members of the Tempo program/team; name or id). Filters combine as a union. Viewing others requires the Tempo token owner to have a Permission Role with 'View Worklogs' plus Jira 'Browse Projects' — otherwise Tempo silently returns only permitted worklogs. |
| createWorklogD | – |
| bulkCreateWorklogsD | – |
| editWorklogD | – |
| deleteWorklogD | – |
| getMissingWorklogDaysA | Find working days in a date range where the user's logged time is below the expected hours from their Tempo user-schedule. Holidays and non-working days are skipped automatically. Returns days with their expected vs logged hours, plus a per-issue breakdown for partially-logged days. Requires the 'Schemes' scope on the Tempo API token (in addition to 'Worklogs'). Pass 'users' / 'program' / 'team' to check other people instead — returns a per-user report (requires permission to view their worklogs and schedules). |
| getWorklogAnalyticsA | Aggregate worklogs in a date range and return hours, worklog count, and percentage per group, sorted by hours descending. groupBy options: 'issue' (default), 'account', 'user', 'day', 'week' (ISO 8601), 'month'. Pass 'users' / 'program' / 'team' to analyze other people's worklogs (e.g. groupBy 'user' + program gives a per-person report for the whole program; requires 'View Worklogs' permission). Note: 'account' grouping reads the Account work attribute on each worklog — worklogs without an account attribute are bucketed as 'No account', so this grouping is only meaningful if your team uses Tempo accounts. |
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 7 tools
Four of seven tools (bulkCreateWorklogs, createWorklog, deleteWorklog, editWorklog) lack descriptions, making it hard for an agent to distinguish between them. The three described analytical tools are well-differentiated, but the unknown mutation tools create significant ambiguity.
Naming is inconsistent: uses both 'get' and 'retrieve' prefixes, and mixes singular 'Worklog' with plural 'Worklogs' (e.g., createWorklog vs bulkCreateWorklogs). This lack of pattern reduces predictability.
With 7 tools, the server covers core CRUD and analytical operations for worklog management. The count is appropriate for the scope, though the missing descriptions for half the tools detract from its usability.
Basic CRUD (create single/bulk, delete, edit) and analytics (retrieve, analytics, missing days) are present, suggesting reasonable coverage. However, the lack of descriptions makes it unclear if there are gaps like a 'get by ID' or bulk delete.