Skip to content
FullCalendar WebMCP
Esc
↑↓navigate↵open⌘Jpreview
On this page

Repository Contract

Connect WebMCP calendar tools to your existing API or database with list, get, create, update, and delete.

WebMCP calendar tools call an object you provide — CalendarEventRepository with five methods that wrap your existing API or database.

Pass it as the events option to useFullCalendarWebMCP.

Authorization and authentication are host-owned. The repository must enforce the same rules for agent and UI traffic. See Security.

One source of truth

FullCalendar WebMCP does not store events. Human UI edits and agent tool calls both go through your repository. After an agent mutation, onEventsChanged refreshes the UI from that same source.

Human (FullCalendar UI) ──┐
                          ├──→ your persistence ──→ onEventsChanged ──→ FullCalendar
Agent (WebMCP tools) ─────┘

Reject a repository promise and the tool fails — no second copy of events to drift out of sync.

Methods

Method Purpose
list Return events, optionally filtered by range or title text
get Return one event by id, or null
create Persist a new event and return it with its id
update Apply changes and return the updated event
delete Remove an event by id
export interface CalendarEventRepository {
  list(
    query?: CalendarEventQuery,
    options?: { signal?: AbortSignal },
  ): Promise<CalendarEvent[]>;

  get(
    id: string,
    options?: { signal?: AbortSignal },
  ): Promise<CalendarEvent | null>;

  create(
    input: CreateCalendarEventInput,
    options?: { signal?: AbortSignal },
  ): Promise<CalendarEvent>;

  update(
    id: string,
    input: UpdateCalendarEventInput,
    options?: { signal?: AbortSignal },
  ): Promise<CalendarEvent>;

  delete(
    id: string,
    options?: { signal?: AbortSignal },
  ): Promise<void>;
}

Filters on list

export interface CalendarEventQuery {
  start?: string; // inclusive ISO 8601
  end?: string;   // exclusive ISO 8601
  text?: string;  // case-insensitive title substring
}

Cancellation

Every method accepts an optional { signal?: AbortSignal }. Forward it to fetch when you want aborted agent calls to cancel in-flight requests.

Any backend

REST, Server Actions, Supabase, Prisma, GraphQL, or an in-memory store for prototypes all work — as long as the same operations serve humans and agents.

For domain mapping and optional metadata, see Custom event models.

Was this page helpful?