Think inside your AI world.

Cal.com through Unl

Cal.com can list every booking on the schedule. Whether that adds up to actual coverage for the slot that matters is a separate question, with its own bar.

Cal.com through Unl reads booking, schedule and availability data against the coverage rule you have ratified, so 'is the Tuesday on-call slot covered?' comes back coverage: not closed with the condition it hasn't met.

What Cal.com holds

Cal.com through Unl can genuinely read:

  • All event types and their configuration, plus any single event type by ID.
  • Bookings, filtered and looked up individually, including who's attending.
  • Schedules: a user's default schedule and every schedule defined for them.
  • Available time slots and busy times pulled straight from connected calendars.
  • Routing form responses at the organisation level, where a booking was gated by a form.

What the naked read gives you

Cal.com will confirm, exactly, that the Tuesday 9am on-call slot has one booking against it, made by the newest engineer on the rota, with the connected calendar showing no conflicting busy time either side. That's a precise, current read of the schedule as it stands.

The frame judges the data it is given; it does not verify the source’s accuracy.

What changes when Cal.com is read measured

Platform engineering ratified that an on-call slot only counts as covered once the assigned booking belongs to someone who has completed on-call training and has no overlapping busy time logged elsewhere, because a booked slot with an untrained or double-booked engineer isn't real coverage.

'Is the Tuesday on-call slot covered?' returns, measured: coverage: not closed - the booking exists, but the assigned engineer's training record is incomplete, failing the ratified condition. Cal.com supplied the booking and busy-time data; your ratified rule supplied the coverage definition.

And back again

Whoever runs the next rota review doesn't start from a blank schedule grid. The same coverage call is already sitting against Tuesday's slot, built from the same rule the rest of the rota gets checked against.

The answer comes back measured against what you already decided, and why.

The lane is live and open to this tool today: one box, paste anything. If it speaks MCP, Unl can reach it. Readings arrive unprompted, the data beside the criterion; Unl is a courier, not a warehouse, and keeps only your keys and the frame.

Questions people ask

Does the coverage verdict change once training is completed?

Yes. Unl re-reads Cal.com's booking and schedule data each time it's asked, so once the assigned engineer's training record clears and no conflicting busy time exists, the same slot returns covered on the next check.

How do I connect Cal.com to Claude?

Add Cal.com's own hosted MCP server, at mcp.cal.com, as a source in Unl and complete the OAuth flow. Unl then reads whatever bookings, schedules and availability that authenticated account can already see.

Can Unl create or move a Cal.com booking through this connection?

No. Reading is the whole job here: Unl checks bookings, schedules and busy times against your ratified coverage rule. Creating, rescheduling or cancelling a booking isn't something this connection does.

What this is

Think inside your AI world — you stay in command

Unlimitless (Unl to friends) holds what you've settled, reads what your tools are showing, and catches what's changed out in the world — and hands your AI whatever bears on the work, the moment it's needed, without you asking. The right thing, in front of the model, unprompted, with you in command of the call. So you keep moving toward what you set out to build, on top of everything you've already decided.

It plugs into Claude, Claude Code, ChatGPT and Cursor as an MCP connector. Quick to connect, in a couple of steps.

Unlimitless is open now to invited Alpha. Apply for the Beta waitlist to come in ahead of the full launch:

Alpha is invite-only · free at launch.