Cancelling a booking releases the slot and notifies the host and every attendee, and nothing brings it back — so the tool description itself carries the stop, telling the agent to name the booking, state that it is permanent, and wait for written confirmation. Everything else that mutates returns the before and after state in the same response, which is the practical version of an undo log for an API that does not keep one.
An MCP server over Cal.com's v2 API covering a scheduling account end to end — the event types you offer, the bookings against them, the schedules that define your availability, and the organisation memberships and routing forms around them. It is a hosted server reached through a MewCP account, which holds the Cal.com credential on your behalf.
- Event types read and created — `get_event_types`, `get_event_type` by ID, `create_event_type` — plus `get_my_profile` for the authenticated user's timezone, locale, week start and default schedule
- Bookings across their whole life: `get_bookings`, `get_booking`, `create_booking` from an event type ID, an ISO 8601 start time and the attendee's name and email, then `reschedule_booking`, `confirm_booking` for a pending one, and `mark_booking_absent`
- Every mutating call returns both the before and the after state, so you have a record of what changed even though the original is not stored anywhere
- `cancel_booking` marked destructive and irreversible in its own description, with an instruction not to call it autonomously — the agent is told to name the booking, say the cancellation is permanent, and wait for explicit written confirmation first
- Availability: `get_availability` returns the open slots for one `YYYY-MM-DD` day with attendee counts, and `get_busy_times` returns busy blocks pulled from the connected calendars with their source
- Schedules — `get_schedules`, `get_schedule`, `get_default_schedule` and `create_schedule` — each carrying its timezone, weekly availability windows and overrides
- Organisation context via `get_org_memberships` (roles, acceptance state, the member's user record) and `get_org_routing_forms` (routes, fields and enabled state)
- One response envelope on every tool: `success`, `statusCode`, `retriable`, `retry_after_seconds`, `error` and `data`, where `retriable` is true only for rate limits, network errors and 503s, and error codes are `VALIDATION_ERROR`, `AUTH_ERROR`, `UPSTREAM_ERROR` or `SERVER_ERROR`
A Cal.com API key, created at Cal.com Settings → Developer → API Keys and copied once, since it is only shown at creation. The key is added to your MewCP account as the `api_key` credential field rather than pasted into a local config; the server sends it upstream as a bearer token together with the Cal.com API version header. Requests carry an `X-Mewcp-Credential-Id` header identifying which credential to use. Calls consume credits against your MewCP plan, and running out surfaces as an insufficient-credits error rather than a Cal.com failure.