The hard part of time tracking is never starting the timer, it is the entry you forgot to stop and the two hours you have to attribute after the fact. Both add_timespan and update_timespan take explicit times, so an afternoon can be reconstructed in one exchange.
A server in front of a Traggo instance's GraphQL API. Twelve tools cover running timers, completed timespans and the tag definitions Traggo organises time with. The server is stateless — the Traggo device token you send is the entire auth state.
- A timer started with tags and a note, starting now unless you say otherwise
- A running timer stopped by id, ending now unless you say otherwise
- A completed timespan recorded with explicit start and end
- A timespan's start, end, tags or note edited, or the timespan deleted
- Running timers listed, and recorded timespans listed within an RFC3339 range
- Tag definitions listed with key, colour and usage count, then created, recoloured, renamed or deleted
- A diagnostic call that confirms the token is wired up correctly
A Traggo instance and a device token from it. The server ships a /login page: sign in with your Traggo username and password and copy the token it shows. Your MCP client then sends that token to /mcp as an Authorization Bearer header. Nothing is stored server-side.