GudCal is live: source-available scheduling that AI agents can operate

Calendly taught the internet that a link can replace the "when are you free?" email thread. That product is still excellent at what it was designed for: humans clicking a polished booking page.

It was not designed for an AI agent that needs to discover event types, read real availability, and create a booking without a browser. Calendly is closed-source and prices by seat. Cal.com is open-source, but it is a large monorepo — powerful, and heavy to run or fork if you only want a scheduling primitive.

GudCal is the third path: a source-available scheduling engine small enough to self-host, with a Model Context Protocol (MCP) server that exposes the full booking lifecycle as 21 tools.

Star the repo: github.com/gudlab/gudcal-core Try Cloud Free: gudcal.com/register Book a live demo slot: gudcal.com/demo/meeting

Why MCP, not "just an API"

REST is necessary. GudCal ships /api/v1 (profile, event types, availability, bookings, API keys) plus HMAC-signed webhooks for BOOKING_CREATED, BOOKING_CONFIRMED, BOOKING_CANCELLED, BOOKING_RESCHEDULED, BOOKING_REMINDER, and MEETING_ENDED. Keys use a gck_ prefix.

Agents still do better with MCP. A model does not want to read OpenAPI and invent a client; it wants a tool list with schemas. GudCal's MCP server is a Next.js App Router route at POST /api/mcp. Each request constructs a fresh McpServer and a WebStandardStreamableHTTPServerTransport in stateless mode — no session store, no sticky connections. Point Claude Desktop, Cursor, or any HTTP MCP client at https://gudcal.com/api/mcp.

On GudCal Cloud, that MCP surface is a Team plan feature (organizations at $20/month). The implementation lives in the BSL 1.1 source, so you can read every handler in lib/mcp/server.ts.

21 tools, two auth models

Four tools are public. They are the guest-agent loop: find what someone offers, ask when they are free, book, or cancel as the guest.

Seventeen tools require an API key. After a human registers and creates one key in the dashboard, an agent can run the host side:

• Profile: get_profile, update_profile
• Event types: get_my_event_types, create_event_type, update_event_type, delete_event_type
• Schedules: list_availability_schedules, create_availability, update_availability, delete_availability
• Host bookings: get_bookings, confirm_booking, cancel_booking_as_host, mark_no_show
• Keys: list_api_keys, create_api_key, revoke_api_key

create_event_type is not a title-and-duration stub. It accepts location (IN_PERSON, GOOGLE_MEET, ZOOM, PHONE, CUSTOM), buffers before/after, minimum notice, max bookings per day, slot interval, confirmation requirement, color, and a linked availability schedule. create_availability takes IANA timezones and multiple rules per weekday (split morning/afternoon blocks).

A typical guest-agent conversation is three calls:

list_event_types(username: "demo")
get_availability(username: "demo", eventSlug: "meeting",
                 dateFrom: "2026-09-22", dateTo: "2026-09-26",
                 timezone: "America/New_York")
create_booking(username: "demo", eventSlug: "meeting",
               startTime: "2026-09-23T15:00:00.000Z",
               guestName: "Ada", guestEmail: "ada@example.com")

You can run that path yourself against the live demo: gudcal.com/demo/meeting.

The availability engine agents actually need

MCP is useless if slot math is wrong. GudCal's scheduler (lib/availability.ts) computes UTC slots from weekly rules, date overrides, duration, slot interval, buffers, minimum notice, and optional max-bookings-per-day. It overlays existing bookings and Google Calendar FreeBusy so a slot that looks open on the booking page is not already a conflict on the host calendar.

Organizations (Cloud Team) get round-robin (load-balanced across members who are actually free) and collective scheduling in lib/scheduling.ts — not enum stubs. That matters when an agent books "a 30-minute intro with the team" rather than a named human.

Next.js 16, not a scheduling monorepo

GudCal is one Next.js 16.1 App Router app: React 19, Prisma 7, PostgreSQL, Auth.js v5 (Google + credentials), Tailwind CSS 4 / shadcn, Resend + React Email, Stripe on Cloud. Docker Compose brings up Postgres 16 and the app with NEXT_PUBLIC_IS_SELF_HOSTED=true.

That is the contrast with Cal.com. Cal.com is a serious product with a large surface area (apps, atoms, many packages). If you want to self-host "scheduling plus every integration," that size is justified. If you want a codebase an agent — or a small team — can read in an afternoon, a single Next.js app with Prisma is a different bet. GudCal takes the second bet on purpose.

Self-host for your own organization:

git clone https://github.com/gudlab/gudcal-core.git
cd gudcal-core
cp .env.example .env.local
# set DATABASE_URL, AUTH_SECRET, NEXT_PUBLIC_APP_URL, ENCRYPTION_KEY
docker compose up -d

Required env is small: DATABASE_URL, AUTH_SECRET / NEXTAUTH_SECRET, NEXT_PUBLIC_APP_URL, Google OAuth if you want that login, ENCRYPTION_KEY for calendar tokens. Optional: Resend, Stripe, Google Calendar OAuth, CRON_SECRET for the 24h reminder job.

License: BSL 1.1, not MIT

GudCal is source-available, not MIT. The Business Source License 1.1 lets you read, modify, and self-host for your own use. It does not let you offer GudCal (or a substantially similar derivative) as a competing commercial hosted scheduling service.

On February 18, 2030 the licensed work converts to Apache License 2.0. Until then, Cloud is how we fund the project; the GitHub repo is how you audit it.

Cloud pricing (no per-seat tax)

Hosted plans are flat, not Calendly-style per-seat:

Free is enough to put a real booking page in production. Upgrade when you need more event types, team assignment, or agents on the hosted MCP endpoint.

What to do next

1. Star github.com/gudlab/gudcal-core if agent-native, self-hostable scheduling is a product you want to exist.
2. Create a Cloud Free account at gudcal.com/register — three event types, unlimited bookings, no credit card.
3. Book the live demo at gudcal.com/demo/meeting and watch the same availability engine MCP calls.

If you are wiring an agent today, start with the public tools against a username, then hand the agent a gck_ key on Team when it needs to own event types and host-side booking ops. Docs: MCP reference and self-hosting.