How do I let an AI assistant book meetings without giving it access to my calendar?

Most confusion here comes from one phrase covering three very different levels of exposure. Worth separating before you decide.

• Raw calendar access. An OAuth grant against Google Calendar or Microsoft 365 that can list events with titles, attendees, locations and descriptions. This is the broadest, and it is what most people are actually worried about.
• Scheduling-account access.Access to a scheduling product's own data — your event types, booking history, who booked you and what they wrote in the intake form. Less than your raw calendar, but often still sensitive.
• Computed availability. A derived list of open slots — start and end times, nothing else. The underlying events are read server-side to work out what is free, and never returned.

An assistant that can only see the third category cannot tell you who someone is meeting on Thursday, because that information never reaches it.

Calendly and Cal.com both ship official remote MCP servers. You authenticate with OAuth 2.1, and your assistant gets a broad tool surface — roughly 35 tools each — covering availability, event types, creating and rescheduling bookings, and organisation management.

This is the right choice when you want an assistant to run your scheduling for you: tidy up your event types, reschedule a cluster of meetings, pull up who booked you last week. The tools are scoped to the account that authorised them, and the assistant acts as you.

The trade-off is scope. Anything your assistant can read, it can also surface in a conversation, include in a summary, or pass to another tool. If that assistant is shared, automated, or occasionally untrusted, the exposure is your booking history rather than a list of free times.

The narrower pattern puts a boundary in a different place: the server computes free/busy internally and exposes only the result. Lucie Sync works this way. Its connector has five tools, and none of them can return a calendar event — not a title, not an attendee, not a description. There is no such tool to call.

That constraint is what makes it safe to point someone else'sassistant at you. A booking endpoint that can only ever answer “here are open 30-minute slots next week” does not become more dangerous because an unfamiliar agent is the one asking.

The cost is real: an availability-only endpoint cannot do the account management work Option A is good at. It answers a narrower question.

Do not rely on the marketing copy. Any MCP client can list a server's tools, and the tool list is the honest description of its capabilities. Three things to look at:

• The tool names and descriptions. If a tool returns events, bookings or attendees, the assistant can see events, bookings and attendees.
• The annotations. Well-built servers mark each tool readOnlyHint or destructiveHint, and a good client uses those to prompt you before a write runs.
• What the OAuth consent screen asks for. If connecting the scheduling tool requires granting calendar scopes to a third party, the boundary is wherever that party chooses to put it.

If the assistant is yours, the account is yours, and you want it doing real work on your scheduling, Option A gives you more. If you are publishing an endpoint that other people — and increasingly other people's agents — will reach, Option B limits what a mistake can cost.

They are not exclusive. Running an account-scoped server for your own assistant and an availability-only endpoint for everyone else is a coherent setup, and probably where most people land.

Details of the availability-only approach are in the Lucie Sync connector docs, and a side-by-side of all three servers is in which scheduling tools have an MCP server.