drytrix-timetracker-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TT_TIMEOUT | No | Per-request timeout (seconds) | 30 |
| TT_BASE_URL | Yes | Instance root, e.g. https://time.example.com | |
| TT_PER_PAGE | No | Page size for paginated reads | 100 |
| TT_API_TOKEN | No | Alias for TIMETRACKER_API_KEY | |
| TT_VERIFY_SSL | No | Verify TLS certificates | true |
| TT_ENABLE_WRITE | No | Register the write tools | false |
| TIMETRACKER_API_KEY | No | API token (tt_…); TT_API_TOKEN is an alias |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| api_infoA | Get the TimeTracker API version, timezone, and enabled modules (no auth). |
| whoamiA | Get the user this token authenticates as (needs read:users). |
| list_projectsC | List projects (needs read:projects). |
| list_time_entriesC | List time entries in a date range (needs read:time_entries). |
| get_hours_summaryC | Total and billable hours plus per-project breakdown (needs read:reports). |
| hours_by_dayB | Per-day hours from time entries, the authoritative hours source (needs read:time_entries). |
| list_clientsA | List clients (needs read:clients). |
| list_tasksC | List tasks (needs read:tasks). |
| searchC | Search projects, tasks, clients, and entries (needs read:projects). |
| timer_statusA | Get the active timer for the token's user (needs read:time_entries). |
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 10 tools
Most tools target clearly distinct resources: clients, projects, tasks, users, timer status, and API metadata. The one genuine overlap is get_hours_summary vs hours_by_day, both reporting hours, though the descriptions clarify that one is a billable/total rollup and the other is the authoritative per-day source. search also lightly overlaps with the list_* tools but is framed as a cross-entity search.
Five tools follow a clean list_noun pattern (list_projects, list_clients, list_tasks, list_time_entries), but the rest deviate: bare nouns (whoami, api_info, timer_status), a bare verb (search), a get_ prefix (get_hours_summary), and a noun_phrase (hours_by_day). The names are individually readable but there is no single predictable convention an agent can rely on.
Ten tools is well within the sweet spot for a time-tracking server, and each covers a distinct slice of the domain (metadata, identity, projects, clients, tasks, entries, summaries, timer, search). Nothing feels padded or redundant in count.
The surface is entirely read-only: there is no way to start/stop a timer, log or edit a time entry, or create projects/tasks/clients, even though timer_status implies an active-timer lifecycle exists. For a time tracker, the inability to record time is a significant gap that will block common agent workflows.