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 resources (plans, teams, accounts, timesheets) are clearly distinct, and descriptions cross-reference each other well (e.g. get_worklogs pointing to by_team/by_account, and search_accounts explaining key→id resolution). However, there are seven overlapping worklog readers (get_worklogs, by_issue, by_team, by_account, by_project, by_user, search_worklogs) whose boundaries blur, inviting misselection.
Tool names uniformly use a tempo_ prefix with a predictable verb_noun pattern (get_, create_, update_, delete_, search_, submit_, approve_). Conventions are consistent throughout, with only the trivial tempo_healthcheck deviating.
48 tools is heavy for the scope, and the count is inflated by the redundant worklog-read cluster and many single-resource getters. While the domain is broad, several tools could be consolidated via filtering parameters rather than dedicated endpoints.
Core domains (worklogs, plans, teams, accounts) have full CRUD, and the timesheet approval lifecycle is well-covered end to end (submit/approve/reject/reopen/recall plus status/reviewer/audit reads). Minor gaps remain: projects and account categories are read-only, and periods/work attributes are get-only.