tempo-api-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_CONFIRM_MODE | No | What a write does on a client that cannot show a confirmation prompt (claude.ai, Claude Desktop). 'ask-user': two steps — the first call does nothing and returns a preview plus a token, and the model must get your approval in chat before calling again with it. 'auto': the same two steps, but the model may use the token after reviewing the preview itself. 'refuse': writes are refused on such clients. A client that can show prompts (Claude Code) always gets the real prompt. An unrecognised value is treated as 'refuse'. | ask-user |
| MCP_CONFIRM_SECRET | No | Signing key; set it only if tokens must survive a server restart. | random per process |
| MCP_CONFIRM_TTL_SECONDS | No | How long a token stays valid. | 600 |
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_worklogsB | Retrieve a list of Tempo worklogs matching the given search parameters. Supports filtering by project, issue, date range, and more. |
| tempo_get_worklogA | Retrieve a single Tempo worklog by its id. |
| tempo_create_worklogA | Create a new Tempo worklog. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_update_worklogA | Update an existing Tempo worklog by id. Supply only the fields to change. Fields you omit keep their current values: the tool reads the current resource and merges your fields over it (Tempo's PUT replaces the whole resource, so an update built from only the changed fields would wipe the rest). That read runs on every call, so the preview shows the full merged body, and a resource that changes between the preview and the confirmed call is refused rather than overwritten. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_delete_worklogA | Delete a Tempo worklog by id. bypassPeriodClosuresAndApprovals can rip a worklog out of an already-approved timesheet, so the preview surfaces the bypass flag. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_search_worklogsA | Search Tempo worklogs using a POST body with advanced filters (author ids, issue ids, project ids, date range). For team or Tempo-account filters use tempo_get_worklogs_by_team / tempo_get_worklogs_by_account. |
| tempo_get_worklogs_by_userB | Retrieve all Tempo worklogs for a specific user (Atlassian account id). |
| tempo_get_worklogs_by_projectB | Retrieve all Tempo worklogs for a specific Jira project. |
| tempo_get_worklogs_by_issueC | Retrieve all Tempo worklogs for a specific Jira issue. |
| tempo_get_worklogs_by_teamC | Retrieve all Tempo worklogs for a specific Tempo team. |
| tempo_get_worklogs_by_accountA | Retrieve all Tempo worklogs associated to a Tempo account key. |
| tempo_get_plansA | Retrieve a list of Tempo plans (resource allocations) matching the given parameters. Requires from and to dates. |
| tempo_get_planA | Retrieve a single Tempo plan (resource allocation) by id. |
| tempo_create_planA | Create a new Tempo plan (resource allocation) for a user or generic resource against an issue or project. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_update_planA | Update an existing Tempo plan (resource allocation) by id. Supply only the fields to change. Fields you omit keep their current values: the tool reads the current resource and merges your fields over it (Tempo's PUT replaces the whole resource, so an update built from only the changed fields would wipe the rest). That read runs on every call, so the preview shows the full merged body, and a resource that changes between the preview and the confirmed call is refused rather than overwritten. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_delete_planA | Delete a Tempo plan (resource allocation) by id. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_get_teamsA | Retrieve a list of Tempo teams. Can filter by name, member account ids, or specific team ids. |
| tempo_get_teamA | Retrieve a single Tempo team by id. |
| tempo_create_teamA | Create a new Tempo team. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_update_teamA | Update an existing Tempo team by id. Supply only the fields to change. Fields you omit keep their current values: the tool reads the current resource and merges your fields over it (Tempo's PUT replaces the whole resource, so an update built from only the changed fields would wipe the rest). That read runs on every call, so the preview shows the full merged body, and a resource that changes between the preview and the confirmed call is refused rather than overwritten. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_delete_teamA | Delete a Tempo team by id. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_get_team_membershipsA | Retrieve all memberships for a single Tempo team. To filter across teams — or by account or role — use tempo_search_team_memberships. |
| tempo_search_team_membershipsB | Search Tempo team memberships across teams, accounts, and roles via POST. Inactive memberships are included. |
| tempo_get_accountsA | Retrieve a list of all Tempo accounts (OPEN and CLOSED). |
| tempo_get_accountA | Retrieve a single Tempo account by its numeric id. Only update/delete address an account by key — to go from a key to an id, use tempo_search_accounts with keys: ["ACCOUNT-123"]. |
| tempo_search_accountsA | Search Tempo accounts by id, key, status, or global flag. This is also how you resolve an account key to the numeric id that tempo_get_account needs. |
| tempo_create_accountA | Create a new Tempo account. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_update_accountA | Update an existing Tempo account by its key. Supply only the fields to change. Fields you omit keep their current values: the tool reads the current resource and merges your fields over it (Tempo's PUT replaces the whole resource, so an update built from only the changed fields would wipe the rest). That read runs on every call, so the preview shows the full merged body, and a resource that changes between the preview and the confirmed call is refused rather than overwritten. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_delete_accountA | Delete a Tempo account by its key. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_get_account_categoriesA | Retrieve all Tempo account categories, or a single category when id is given. This endpoint is not paginated. |
| tempo_get_projectsA | Retrieve a paginated list of all Tempo Financial Manager projects. |
| tempo_get_projectA | Retrieve a single Tempo Financial Manager project by id. |
| tempo_get_timesheet_approval_statusB | Retrieve the current timesheet approval status for a user in the given period. |
| tempo_get_timesheet_approvals_waitingA | Retrieve all timesheets that are currently waiting for approval. |
| tempo_get_timesheet_approvals_by_teamA | Retrieve every team member's timesheet approval for the given period — the reviewer's view of who has submitted, who is still open, and who has been approved. |
| tempo_get_timesheet_reviewersA | Retrieve the users who can review a given user's timesheet. Use this to source |
| tempo_search_timesheet_approval_logsA | Search timesheet approval audit logs. Requires appropriate Tempo permissions; results may contain PII (account ids, reviewer actions). Paginated via nextPageToken from the previous response. |
| tempo_submit_timesheetA | Submit a user's timesheet for the given period for approval, moving it from OPEN to WAITING_FOR_APPROVAL. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_approve_timesheetA | Approve a user's submitted timesheet for the given period. Reviewer action — approving locks the period's worklogs against further edits. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_reject_timesheetA | Reject a user's submitted timesheet for the given period, sending it back to the user for changes. Reviewer action — supply a comment explaining why. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_reopen_timesheetA | Reopen a user's already-approved timesheet for the given period, returning it to OPEN so worklogs can be edited again. Reviewer action — this undoes an approval. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_recall_timesheetA | Recall a user's own timesheet that was submitted but not yet approved, returning it to OPEN so it can be corrected and resubmitted. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| tempo_get_periodsA | Retrieve Tempo period definitions (used for timesheet approval cycles). |
| tempo_get_user_scheduleA | Retrieve the work schedule for a user, including planned working hours per day. |
| tempo_get_global_configurationB | Retrieve the global Tempo configuration settings. |
| tempo_get_work_attributesB | Retrieve all Tempo work attributes (custom fields on worklogs). |
| tempo_get_rolesA | Retrieve all Tempo roles. |
| tempo_healthcheckA | Resolves the credential the way real tools do, then makes one authenticated request to api.tempo.io. Reports which source supplied the credential, whether api.tempo.io accepted it, the round-trip time, and a plain-English hint distinguishing 'no credential' from 'credential rejected' from 'a api.tempo.io-side problem'. Read-only; never returns the credential itself. Call this when a real tool fails and you want to know which hop broke. |
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 48 tools
Most tools have clear verb_noun names, but the worklog retrieval family is oversized and overlapping: tempo_get_worklogs already supports filtering by project/issue, making tempo_get_worklogs_by_project and tempo_get_worklogs_by_issue redundant, and tempo_search_worklogs overlaps with both. Descriptions help distinguish the by_team/by_account variants, but an agent could easily misselect.
All tools follow a consistent tempo_<verb>_<object> pattern in snake_case, which is strong. Minor deviations like tempo_get_timesheet_approvals_waiting (odd phrasing) and singular/plural inconsistencies (approval vs approvals) prevent a perfect score.
48 tools is far beyond the typical 3-15 for a coherent MCP server and above the 25+ threshold. The worklog retrieval family alone has 7 near-overlapping tools, inflating the count. While Tempo is a broad domain, the surface could be consolidated.
The server covers CRUD for worklogs, plans, teams, and accounts, plus a full timesheet approval workflow. However, it provides no way to create, update, or delete team memberships, and only read access to account categories, roles, and periods, which are notable gaps for a supposedly comprehensive Tempo API surface.