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
Save the thoughts, decisions and targets worth keeping, each with its reasoning, carried into every AI session the moment they matter. A new unit of exchange between you and your AI: the Settled Why with standing that travels. Unprompted.
Your whole AI world. What you decided at the epicentre. It plugs into Claude, Claude Code, ChatGPT and Cursor as an MCP connector — quick to connect, in a couple of steps.
MCP native·Human settled·Model agnostic·Your data
Measured Context
Connect Unl to bring the right information into the moment.
Your sources, read against the criteria you set.
The full product, open. Free at launch.