Teamup Calendar MCP by usefulapi

The calendar this connection points at: title, timezone and date settings, custom event fields, sub-calendars, the permission of the calendar key in use and the plan's features. Call this first to learn the sub-calendar ids and the timezone. The calendar key itself is never returned. GET /{calendarKey}/configuration.

List the sub-calendars (the colored lanes that events belong to, such as people, rooms or resources). A key with admin permission also sees inactive ones. GET /{calendarKey}/subcalendars.

One sub-calendar by id: name, color, overlap rule, active state and which links may use it. GET /{calendarKey}/subcalendars/{id}.

List the calendar's access keys (sharing links and user accesses) with name, role, active state and per-sub-calendar permission. Needs a key with admin permission. The secret key values are never returned (they are secrets); use the id and name to tell links apart. GET /{calendarKey}/keys.

List the events in a date range, optionally only on some sub-calendars. Recurring events are expanded: every occurrence in the range is returned with its own id (series id + -rid- + start). Notes come as markdown. Times use the calendar's timezone unless tz is set. GET /{calendarKey}/events.

Search events by keyword (2-100 characters) within a date range (default: today only, so always pass the range you mean). Recurring events are expanded. Paged with limit and offset. GET /{calendarKey}/events?query=.

One event by id: title, times, sub-calendars, location, who, notes (markdown), recurrence rule, custom fields, signups, comments, attachments (metadata), version, change history and reminders. Use the occurrence id (123-rid-<unix start>) for one occurrence of a recurring event. GET /{calendarKey}/events/{id}.

Events created, changed or deleted since a Unix timestamp (at most 30 days back), for syncing. A recurring event comes back once, as its series, not as occurrences. Deleted events carry delete_dt. Pass the reply's timestamp as since_timestamp next time so nothing is missed. GET /{calendarKey}/events?modifiedSince=.

The people signed up for an event (name, email, id). Signups must be enabled on the event. GET /{calendarKey}/events/{id}/signups.

WRITE: create an event. Needs a calendar key with add or modify permission. Give at least subcalendar_ids, start and end. Not idempotent: a repeated call creates a second event. The reply holds the new event and an undo_id; teamup_undo_event_action removes the event again within one hour. POST /{calendarKey}/events.

WRITE: change fields of an event; fields you leave out keep their value (the event is read first and sent back with its version, so a concurrent edit is refused instead of overwritten; an event without a version is not changed). Needs modify permission. For a recurring event pass redit; use the occurrence id (123-rid-<unix start>) with single or future. Attachments are not touched. The reply holds

WRITE, DESTRUCTIVE: delete an event, or for a recurring event the chosen occurrences. Needs modify permission. Not retried. The reply holds an undo_id; teamup_undo_event_action restores the event within one hour, after that the deletion is permanent. For one occurrence use the occurrence id (123-rid-<unix start>) and redit single (the default); redit all deletes the whole series. DELETE /{calendar

WRITE: undo a recent event creation, update or deletion with the undo_id from that call. Works for one hour only and is refused if someone else changed the event since. PUT /{calendarKey}/events/undo/{undo_id}.

WRITE: create a sub-calendar. Needs a calendar key with admin permission, and the plan may limit how many exist. Not idempotent: a repeated call creates a second one. POST /{calendarKey}/subcalendars.

WRITE: change a sub-calendar's name, color, overlap rule or active state; fields you leave out keep their value. Needs admin permission. Making a sub-calendar inactive hides it from users without admin rights. PATCH /{calendarKey}/subcalendars/{id}.