tempo-api-mcp
# tempo-api-mcp
[](https://github.com/chrischall/tempo-api-mcp/actions/workflows/ci.yml)
[](https://www.npmjs.com/package/tempo-api-mcp)
[](LICENSE)
Tempo API MCP server for Claude — developed and maintained by AI (Claude Code)
## Confirmations
Every write (create/update/delete, and the timesheet submit/approve/reject/reopen/recall actions) asks the user to confirm before it changes anything: a confirmation prompt where the client supports one; otherwise the first call returns a preview of exactly what would be sent plus a `confirmToken`, and only a repeat call with that token proceeds.
| variable | default | |
|---|---|---|
| `MCP_CONFIRM_MODE` | `ask-user` | 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) gets the real prompt unless `MCP_CONFIRM_ELICITATION=off`. An unrecognised value is treated as `refuse`. |
| `MCP_CONFIRM_ELICITATION` | `on` | `off` never shows a confirmation prompt, so every client gets the `MCP_CONFIRM_MODE` two-step flow. **Set it for opencode v2**: it claims to support prompts but never displays them, so writes (including timesheet approvals) hang. Any other value stays `on`. |
| `MCP_CONFIRM_TTL_SECONDS` | `600` | How long a token stays valid. |
| `MCP_CONFIRM_SECRET` | random per process | Signing key; set it only if tokens must survive a server restart. |
In opencode, set it in the server's `environment` block:
```json
{
"mcp": {
"servers": {
"tempo": {
"type": "local",
"command": ["npx", "-y", "tempo-api-mcp"],
"environment": { "TEMPO_API_TOKEN": "…", "MCP_CONFIRM_ELICITATION": "off" }
}
}
}
}
```
TDQS
Scored across 48 tools
Most tools map cleanly to a resource+action (worklog, plan, team, account, timesheet approval), and descriptions deliberately cross-reference siblings. The weak spot is the retrieval family: tempo_get_worklogs already filters by project/issue, yet separate tempo_get_worklogs_by_project/by_issue/by_user/by_team/by_account and tempo_search_worklogs exist, and get_accounts vs search_accounts / get_team_memberships vs search_team_memberships overlap similarly, so an agent can plausibly pick the wrong retriever.
Nearly every name follows tempo_<verb>_<noun> in snake_case with a predictable verb set (get, search, create, update, delete, submit, approve, reject, reopen, recall). The only non-verb name, tempo_healthcheck, is an obvious and isolated diagnostic outlier.
The Tempo domain is genuinely broad (worklogs, plans, teams, accounts, timesheet approvals, projects, periods, config), so a large surface is defensible. Still, 48 tools is heavy for a single MCP server, and roughly seven near-duplicate worklog retrieval tools plus several redundant search/get pairs inflate the set beyond what the workflows require.
Worklogs, plans, teams, accounts and the timesheet approval lifecycle have full or near-full CRUD coverage, which is strong. But team memberships are read-only (get/search with no add/update/remove), projects have only get/list, and account categories, roles, periods, schedules, work attributes and global config are read-only, leaving real gaps for administrative workflows.