FunkyTime

Get a single project by ID for the authenticated user (resolve ID via list-projects — never guess). Returns activities with id and name — always obtain these once a project is resolved. Use those activity ids for create-time-entry / set-running-time (never ask the user for numeric activity IDs), and match them to activity_id on get-timesheet / get-time-entry / get-running-time when analyzing which activities time was spent on. If the user says something about an activity or a task, treat that as the activity to track on; if the user mentions none, auto-pick an activity only when their description is a great fit for one of them. Also includes frozen_until, project hourly_rate/distance_rate, rate_type (0=project/activity rates, 1=collaborator rates), and per-activity hourly_rate overrides when rate_type is 0 (null override = use project rate). Use this to explain invoice-draft line rates.

get-project

Get the authenticated user's currently running timer, if any. Always returns a stable shape: {running: false, data: null} when idle, or {running: true, data: {...}} when a timer exists (data always includes a uuid — prefer create-time-entry with that uuid for stop-and-save, which clears and links draft expenses). Response start/end are UTC (Z-suffixed). activity_id is numeric (0/null = none) without the activity name — call get-project for the timer's project_id and match activities[].id to interpret it. This is not a saved timesheet entry.

get-running-time

Get a single time entry by ID for the authenticated user. Response start/end are UTC with a Z suffix. activity_id is numeric (0/null = none) without the activity name — call get-project for the entry's project_id and match activities[].id to interpret it.

get-time-entry

Server-side aggregated time/expense totals. Choose this vs get-timesheet by desired result, not period length or project count: use this for totals and breakdowns (group_by project|client|activity|day|week|month), including a single project via project_id. group_by activity returns named labels. Inclusive start/end as YYYY-MM-DD in the user timezone from get-profile (not UTC calendar days); max 366 days. Omit both start and end only with project_id for all-time on that project (then group_by must not be day). Set include_amounts=true to apply rates (see meta.rate_coverage). Use get-timesheet only for line-level entries within 31 days. When answering in local time, do not narrate the timezone unless the user asks or it differs from what they expect.

get-summary

Get line-level time entries for a period (max 31 days). Decide first whether get-summary is a better fit — based on the desired result, not period length or how many projects are involved. Use this tool when you need individual entries (descriptions, exact start/end, editing a row). Use get-summary for totals or breakdowns, even for one project or a short period (e.g. hours by activity or by day on a project: get-summary with project_id + group_by). Do not page this tool and sum client-side; get-summary covers up to 366 days, or all-time on one project_id if start/end are omitted (not group_by day), and with group_by activity returns named labels. start/end are absolute UTC instants (unix or ISO 8601 with Z, e.g. 2026-07-21T22:00:00Z), or YYYY-MM month shorthand. For "today"/"yesterday"/"this week", prefer the user timezone from get-profile (or the best-known user timezone from context) and convert local calendar bounds to UTC — never treat UTC midnight as local midnight. Each entry includes activity_id (numeric; 0/null = none) without the activity name — to analyze which activities time was spent on, call get-project for the relevant project_id(s) and match activities[].id. When answering in the user's local time, do not narrate the timezone unless they ask or it differs from what they expect.

get-timesheet

List the authenticated user's personal clients (slim: id, name, abbreviation). Use get-client for rates and full details. Paginate with limit/offset when meta.has_more is true.

list-clients

List the authenticated user's projects (personal and org). Non-closed only. Check editable before mutating — org/child projects are usually editable: false. frozen_until (YYYY-MM-DD): time entries on or before that date cannot be created, edited, or deleted. When resolving a user-named project (e.g. "networking" or "Odoo"): use query to search; auto-pick only if exactly one result is a plausible match with no near-duplicates. If an exact name coexists with variants (such as a prefix or suffix) or the same name under different clients/billing, present candidates and ask — never silently guess. Activities are omitted by default (property absent) — do not refuse create-time-entry / set-running-time for that reason; call get-project (preferred; includes activity ids + names + rates) or set include_activities=true here for a slim [{id, name}] list. Once a project is resolved, always obtain its activities one of those two ways before saving time on it, and when interpreting activity_id from get-timesheet / get-time-entry / get-running-time. Use get-project for rates, periods, and other full details. Paginate with limit/offset when meta.has_more is true.

list-projects

Set or update the authenticated user's running timer (creates one if none exists). This does not create a saved time entry — use create-time-entry to save. Omitted fields keep their current values — send only the fields you want to change (e.g. description alone does not clear project_id or start). A uuid is always assigned so the timer can later be saved via create-time-entry with that uuid. Be conservative when picking a project. Look for matches in the result of list-projects, and only auto-pick the best match if there is not a single plausible alternative. If alternatives exist, then present them to the user and ask them to pick the right project. Once the project is resolved, ensure that you have obtained its list of activities via get-project (or list-projects with include_activities=true). If the user says something about an activity or a task, treat this as a specification for the activity that this time should be tracked on. If the user does not explicitly mention an activity, then see if the user's description would be a great fit for one of the project's activities: then auto-pick that activity. Never ask the user for numeric IDs. Format start/end as UTC ISO 8601 with Z (unix timestamps are still accepted); a naive datetime is read as local wall-clock in timezone, which must be an IANA identifier such as Europe/Brussels — not CET, CEST, or a numeric offset. If unsure of the user's timezone, call get-profile rather than guessing. When starting a new timer, start defaults to now if omitted. To continue tracking right after a save, prefer create-time-entry with start_next=true over calling this tool; use this tool only when the next timer needs a project, activity, or description of its own.

set-running-time

Update a personal client for the authenticated user. Resolve the client ID via list-clients / get-client — never guess.

update-client

Update an existing project for the authenticated user. Project must be editable (check editable from list-projects / get-project; org/child projects are usually not). closed/archived are booleans (true=set now, false=clear). Pass null to clear nullable fields such as deadline or client_id. Resolve client_id via list-clients / get-client when changing the client.

update-project

Update a time entry. Format start/end as UTC ISO 8601 with Z, and always set timezone to the user's IANA timezone identifier (such as Europe/Brussels — not CET, CEST, or a numeric offset). If unsure, call get-profile first rather than guessing the timezone. To change only the display timezone, re-send start/end exactly as returned (with Z) plus the new timezone — do not strip Z and pair UTC clock values with a local timezone. project_id is required on every update: re-send the entry's current project unless the user asks to move it. When picking a different project, be conservative: look for matches in the result of list-projects, and only auto-pick the best match if there is not a single plausible alternative. If alternatives exist, then present them to the user and ask them to pick the right project. Once the project is resolved, ensure that you have obtained its list of activities via get-project (or list-projects with include_activities=true). If the user says something about an activity or a task, treat this as a specification for the activity that this time should be tracked on. If the user does not explicitly mention an activity, then see if the user's description would be a great fit for one of the project's activities: then auto-pick that activity. Respect project frozen_until (YYYY-MM-DD): entries on or before that date cannot be edited. Optional expenses[] attaches or updates distance/costs in the same call (same shape as update-time-expenses). After successfully updating one or more time entries, present the result in a table with headers on top: Time (from - to, with duration below it), Project (project name, prefixed if relevant; with description below it), Expenses (leave empty if there are none).

update-time-entry

Create, update, or delete expenses for a time entry (by ID) or a draft timer (by UUID). Prefer including expenses[] on create-time-entry / update-time-entry when logging time with distance or costs in one step. Amounts use get-profile currency (ISO code; default EUR); distance (type_id 1) uses get-profile distance_unit (km or mi). Prefer type_id 1 (distance) or 10 (other) unless the user names a specific category; omitted type defaults to 10.

update-time-expenses