timetree-mcp
Related Servers
Alternatives to timetree-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityAmaintenanceEnables calendar management via Infomaniak's API, allowing users to list calendars, search events, and create events.40 npm6MIT
- AlicenseBqualityBmaintenanceEnables MCP clients to access Dooray account, calendar, project, post, attachment, and messenger APIs, with read-only mode and confirmation-gated write tools.15175 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables reading and managing Google Calendar data, including listing calendars, viewing and creating events, checking free/busy schedules, and adding events from natural language.35 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables AI clients to remotely read and edit a single iCloud Calendar account, including events, availability, and invitations, without requiring an Apple device to stay online.13 npmMIT
- AlicenseAqualityBmaintenanceUnofficial MCP server for accessing and managing TimeTree calendar data, including events, memos, and comments, with secure email/password authentication.189 npm15MIT
- AlicenseAqualityDmaintenanceUnofficial MCP server for accessing and managing TimeTree calendar data, supporting events, memos, and comments via email/password authentication.69 npmMIT
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.