Skip to main content
Glama
ehs208

TimeTree MCP Server

by ehs208

create_event

Create a new event in a TimeTree calendar. Supports labels, recurrences, attendees, alerts, and checklists. Requires calendar ID, title, and start/end times.

Instructions

Create a new event in a TimeTree calendar. Requires CSRF token (automatically managed). Returns the created event with UUID. Label colors (label_id 1-10): 1=Emerald green, 2=Modern cyan, 3=Deep sky blue, 4=Pastel brown, 5=Midnight black, 6=Apple red, 7=French rose, 8=Coral pink, 9=Bright orange, 10=Soft violet. Supports checklist, attendees, virtual attendees, alerts, RRULE recurrence strings, and category override.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
calendar_idYesThe calendar ID to create the event in (use list_calendars to get valid IDs)
titleYesEvent title (required)
all_dayNoWhether this is an all-day event (default: false). TimeTree uses inclusive end dates for all-day events.
start_atYesEvent start time as Unix timestamp in milliseconds. For all-day events, use midnight of the start date.
start_timezoneNoStart timezone (default: UTC). Examples: "Asia/Seoul", "America/New_York"
end_atYesEvent end time as Unix timestamp in milliseconds. For all-day events, TimeTree uses an inclusive end date.
end_timezoneNoEnd timezone (default: UTC)
label_idNoColor label ID (1-10). 1=Emerald, 2=Cyan, 3=Blue, 4=Brown, 5=Black, 6=Red, 7=Rose, 8=Pink, 9=Orange, 10=Violet
categoryNoEvent category (default: 1; memos use category=2)
noteNoEvent notes/description
locationNoEvent location
urlNoRelated URL
attendeesNoCalendar user IDs attending this event
recurrencesNoRRULE strings, e.g. ["RRULE:FREQ=DAILY;COUNT=2"]
alertsNoNotification offsets in minutes before the event, e.g. [5, 30]
file_uuidsNoAttached file UUIDs if already uploaded
checklistNoChecklist items to attach to the event
virtual_user_attendeesNoVirtual member IDs/names attending this event
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that the tool creates an event, requires a CSRF token (automatically managed), returns the created event with UUID, and supports various features (checklist, attendees, alerts, recurrences). It also explains label color mappings and inclusive end dates for all-day events, providing comprehensive behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is five sentences long, front-loading the core purpose. Every sentence provides essential information (returns, CSRF, label colors, supported features) without redundancy. It is efficiently structured and free of fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (18 parameters, 4 required, no output schema) and the context of sibling tools, the description is complete. It covers all major aspects: purpose, return value, required context (CSRF), and supported features. The input schema handles parameter details, so the description does not need to repeat them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by clarifying TimeTree's inclusive end date behavior for all-day events, recommending midnight timestamps for all-day start_at, and listing color mappings for label_id. These details are not present in the schema descriptions and enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a new event in a TimeTree calendar', specifying the verb (create), resource (event), and platform (TimeTree). It further distinguishes from sibling tools like create_memo and update_event by explicitly mentioning features like label colors, checklist, attendees, etc., which are unique to event creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes notes about CSRF token auto-management and the return of the created event with UUID, which aids usage. However, it does not explicitly state when to use this tool over alternatives (e.g., update_event or create_memo) or provide exclusion criteria, leaving some implicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ehs208/TimeTree-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server