Skip to main content
Glama
UtahREIA

addevent-mcp-server

by UtahREIA

Create AddEvent Event

addevent_create_event

Create a new event on your AddEvent calendar. Provide a title and start time, then add optional details like location, recurrence, or reminders to get an event ID and public landing page URL.

Instructions

Creates a new event on an AddEvent calendar.

Args:

  • title (string, required): The event's title.

  • calendar_id (string, optional): Target calendar. Defaults to the account's default calendar. Use addevent_search_calendars to find IDs.

  • datetime_start (string, required): Start date/time, e.g. "2026-09-15 18:00" or "2026-09-15" for a date-only event.

  • datetime_end (string, optional): End date/time. Defaults to datetime_start + 1 hour.

  • all_day_event, timezone, recurring_rule, description, internal_name, location, location_id, organizer_name, organizer_email, reminder, color, free_busy, landing_page_template_id, rsvp_enabled, rsvp_form_id, custom_data: optional fields, see each field's description.

Returns: The created event object as JSON, including its event_id and public landing_page_url.

Examples:

  • "Create the Main Monthly meetup for Sept 15 at 6pm at [venue]" -> title, datetime_start, location set.

  • "Make it a recurring event, third Tuesday of every month" -> recurring_rule: "FREQ=MONTHLY;BYDAY=3TU".

  • Don't use when: the event already exists (use addevent_update_event instead).

Error Handling:

  • Returns a clear message if required fields are missing, the calendar_id doesn't exist, or the API rejects the request body (400).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorNoEvent color, 1 to 20, matching the calendar's palette. Default 1.
titleYesThe event's title. Must be a non-empty, single-line string.
locationNoAddress or URL (e.g. a Zoom link). Mutually exclusive with location_id.
reminderNoMinutes before the event to send a reminder, 0 to 10800. Default 30. Only honored by Apple Calendar, Outlook desktop, and Office 365/Outlook.com.
timezoneNoIANA-style timezone (e.g. 'America/Denver') or 'floating' for a time that stays the same on every viewer's local clock. Defaults to the calendar's timezone. Use addevent_list_timezones for supported values.
free_busyNoWhether the event blocks the attendee's calendar: 'free', 'busy', or 'default' (use their default setting).
calendar_idNoThe calendar this event belongs to. Defaults to the account's default calendar if omitted. Use addevent_search_calendars to find calendar IDs.
custom_dataNoArbitrary key-value metadata to attach to the event, e.g. an external ID linking back to GHL. Use snake_case keys.
descriptionNoPlain text or simplified HTML description. Keep to roughly 500 characters or fewer for cross-browser compatibility.
location_idNoID of a saved location. Mutually exclusive with location.
datetime_endNoEnd date/time, same format as datetime_start. Defaults to datetime_start + 1 hour if omitted.
rsvp_enabledNoIf true, attendees must RSVP before adding the event to their calendar. Default false.
rsvp_form_idNoCustom RSVP form ID, or 'default' for the standard form.
all_day_eventNoIf true, start/end times are ignored and only the date is used. Default false.
internal_nameNoInternal-only label, never shown publicly. Useful for a human-readable label or an external ID linking back to another system.
datetime_startYesStart date/time, e.g. '2026-09-15 18:00' or '2026-09-15' for a date-only event.
organizer_nameNoOrganizer's name. Must be paired with organizer_email.
recurring_ruleNoiCalendar RRULE string for a repeating event (e.g. 'FREQ=MONTHLY;BYDAY=3TU' for the third Tuesday of every month). Leave empty for a one-time event. datetime_start must align with the rule for strict clients like Outlook desktop and Apple Calendar. Not supported by Yahoo Calendar.
organizer_emailNoOrganizer's email. Must be paired with organizer_name. Including an organizer makes calendar clients like Outlook desktop treat this as a meeting rather than an appointment.
landing_page_template_idNoCustom event landing page template ID, or 'default' for the standard AddEvent template.
Behavior5/5

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

Annotations indicate non-read-only, non-idempotent behavior. The description adds valuable behavioral context: error handling for missing fields/invalid calendar_id/400 responses, default behaviors (datetime_end defaults to +1 hour), return value shape (event_id and landing_page_url), and caveats like recurring_rule alignment. This goes well beyond the annotations.

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 appropriately sized for a complex 20-parameter tool. It is well-structured with clear sections: purpose, Args, Returns, Examples, Error Handling, and When-not-to-use. Every section serves a purpose and the key information is front-loaded.

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 high complexity (20 params, no output schema), the description is remarkably complete. It explains return values, error handling, defaults, and use cases. It even addresses edge cases like all-day events and cross-client reminder limitations. The only minor gap is not discussing the openWorldHint annotation, but that is not essential for tool invocation.

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 description coverage is 100%, so the schema already documents all 20 parameters. The description adds a helpful Args summary and examples that map natural language to fields (e.g., 'third Tuesday' -> recurring_rule). While not fundamentally new, the examples and consolidated overview add value above the schema alone.

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 states 'Creates a new event on an AddEvent calendar' with a specific verb and resource. This clearly distinguishes it from sibling tools like addevent_update_event, addevent_delete_event, and addevent_search_events.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance through examples and an explicit 'Don't use when: the event already exists (use addevent_update_event instead).' This directly tells the agent when to avoid this tool and names the alternative.

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/UtahREIA/addevent-mcp-server'

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