fortytimer-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FORTYTIMER_URL | Yes | Base URL of your fortyTimer installation, e.g. https://fortytimer.example.com (for subdirectory installations include the path, e.g. https://example.com/fortytimer/public) | |
| FORTYTIMER_TOKEN | Yes | Your personal API token from fortyTimer → Profile → Security |
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 |
|---|---|
| fortytimer_meA | Identity and visibility scope of the token owner (admin | vorgesetzter/supervisor | mitarbeiter/employee). Useful as a first call to know whose data is returned when no user_id is given. |
| fortytimer_get_overtime_balanceA | Flextime balance (Gleitzeit/overtime account) of a user as of a given date. Defaults to yesterday – the same figure shown on the fortyTimer dashboard. The response contains the exact balance as a signed hours:minutes string (formatted). |
| fortytimer_get_vacation_balanceA | Vacation account of a user for one year: entitlement, carry-over, adjustments, used, remaining and pending (requested but not yet approved) days. Defaults to the current year. Values are day counts; half days (0.5) are valid. |
| fortytimer_list_time_entriesA | Work time entries of a user within a date range (default: last 30 days, max. 366 days), paginated with 50 entries per page. Durations are provided as exact integer minutes (worked_minutes, total_worked_minutes) together with preformatted hours:minutes strings (*_formatted); these minute-exact fields are the authoritative values, decimal hour sums would introduce rounding errors. |
| fortytimer_list_project_timesA | Project time bookings of a user within a date range (default: last 30 days, max. 366 days), optionally filtered by project and billability, paginated with 50 entries per page. Durations are provided as exact integer minutes (minutes, total_minutes) together with preformatted hours:minutes strings (*_formatted); these minute-exact fields are the authoritative values, decimal hour sums would introduce rounding errors. |
| fortytimer_list_requestsA | Leave requests (vacation, flextime, sick leave) within the visibility scope of the token owner, filterable by user, status, type and date range (overlap semantics). Note: free-text fields of sick-leave requests are never returned by the API for data-protection reasons. |
| fortytimer_list_usersA | Users within the visibility scope of the token owner (source of user_id values for the other tools). Active users by default; include_inactive = true also lists deactivated users. |
| fortytimer_list_projectsA | All projects with ID, name and active status (source of project_id values for project time filters). |
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 8 tools
Each tool targets a distinct resource: identity, overtime balance, vacation balance, time entries, project bookings, leave requests, users, and projects. The two time-related list tools are clearly separated by their descriptions, so there is little risk of an agent choosing the wrong one.
The set follows a clear fortytimer_<verb>_<resource> pattern, with list_ for collections and get_ for balances. The only outlier is fortytimer_me, which lacks a verb but is a recognizable identity endpoint, making the naming mostly consistent with a minor deviation.
Eight tools is well-scoped for a time-tracking data server: reference data, balances, and detailed time/request records are each represented without redundancy. No tool feels extraneous, and the count is appropriate for the apparent purpose.
The read-side coverage is strong: identities, balances, time entries, project times, requests, users, and projects are all represented. However, no write or approval operations are exposed, so it cannot drive the full request lifecycle; for a query-oriented assistant this is a minor gap rather than a fatal one.