timetree-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TIMETREE_EMAIL | No | The email address of the TimeTree account used for authentication. | |
| TIMETREE_PASSWORD | No | The password for the TimeTree account. Alternative to providing TIMETREE_PASSWORD_FILE. | |
| TIMETREE_PASSWORD_FILE | No | Absolute path to a password file (with permissions 600) containing the TimeTree password. |
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 | {} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| timetree_list_calendarsA | Read the calendars available in the authenticated TimeTree account. |
| timetree_list_eventsA | Read TimeTree events overlapping a date range. This tool is read-only. |
| timetree_statusA | Read the current direct HTTPS TimeTree authentication status. |
| timetree_loginA | Login to TimeTree over direct HTTPS using TIMETREE_EMAIL and TIMETREE_PASSWORD from the MCP environment; no browser is used. |
| timetree_logoutA | Clear the in-memory TimeTree session cookie and CSRF token. |
| timetree_keychain_statusA | Report whether the macOS Keychain contains TimeTree email/password items; never returns their values. |
| timetree_create_eventB | Create a TimeTree event. Requires confirm=true and writes to the real calendar. |
| timetree_update_eventC | Update selected fields of a TimeTree event. Requires confirm=true. |
| timetree_delete_eventA | Delete a TimeTree event. This cannot be undone and requires confirm=true. |
| timetree_list_memosC | Read category-2 TimeTree memos from a calendar. |
| timetree_create_memoA | Create a TimeTree memo. Requires confirm=true. |
| timetree_update_memoB | Update a TimeTree memo. Requires confirm=true. |
| timetree_delete_memoA | Delete a TimeTree memo. This cannot be undone and requires confirm=true. |
| timetree_list_event_commentsA | Read comments attached to a TimeTree event. |
| timetree_add_event_commentB | Add a comment to a TimeTree event. Requires confirm=true. |
| timetree_update_event_commentC | Update a TimeTree event comment. Requires confirm=true. |
| timetree_delete_event_commentB | Delete a TimeTree event comment. Requires confirm=true. |
| timetree_get_calendar_labelsB | Read all labels for a TimeTree calendar. |
| timetree_update_calendar_labelsA | Merge-update TimeTree label names/colors. Requires confirm=true; omitted labels are preserved. |
| timetree_get_calendar_membersA | Read active members of a TimeTree calendar, optionally including deactivated members. |
| timetree_get_calendar_virtual_membersB | Read virtual members of a TimeTree calendar, optionally including deactivated members. |
| timetree_start_monitorB | Start background polling for calendar changes; changes are sent as MCP notifications/message. |
| timetree_stop_monitorA | Stop the background TimeTree change monitor. |
| timetree_monitor_statusA | Read background monitor state and last error/change information. |
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 24 tools
Tools are organized by clearly distinct resources — calendars, events, memos, comments, auth, and monitoring — so selection is mostly unambiguous. Minor confusion is possible among the three status tools (timetree_status, timetree_keychain_status, timetree_monitor_status), and add_event_comment slightly muddies the otherwise clean create pattern.
The common timetree_ prefix and the verb_noun pattern (list_, create_, update_, delete_) are used consistently across events, memos, and comments. Deviations exist: add instead of create for comments, list vs get alternation for read operations, and non-verb tools like timetree_status and timetree_logout.
24 tools sits at the high end of the borderline-heavy range and feels slightly over-scoped, but the count is defensible because each resource family (events, memos, comments, calendars, monitoring, auth) legitimately needs CRUD or lifecycle coverage. It is not bloated enough to be incoherent, but it is more than strictly necessary.
Events, memos, and comments each have full CRUD coverage, and the authentication and monitoring flows are well supported. Minor gaps exist such as the absence of a single-event fetch, calendar creation/deletion, and label create/delete, but agents can work around these via list operations and the merge-update labels tool.