Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MCP_CONFIRM_MODENoWhat 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_SECRETNoSigning key; set it only if tokens must survive a server restart.random per process
MCP_CONFIRM_TTL_SECONDSNoHow 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 reviewerAccountId for tempo_submit_timesheet and the other approval actions.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 48 tools

Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count2/5

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.

Completeness3/5

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.

Maintenance

ActivityActive
ResponsivenessResponsive