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.