Guide
Letting an AI book meetings on a calendar you actually keep.
Finding an hour that four people can make is the task most worth handing over and the one most easily got wrong. This is what an assistant can see, what it can change, which actions email somebody, and the one answer you must never let it round in your favour. Needs a calendar connected, which is a separate step from connecting the mailbox.
- Reading About 13 minutes
- Works on Microsoft 365, Google, or any CalDAV calendar
- Calendar tools Up to 21, metered like the rest
The short version
Needs a calendar connected: approve calendar access on Microsoft 365, or on any other mailbox sign in to Google or give the address of your calendar server. It reads free/busy rather than other people's meetings. An attendee it cannot see comes back as unknown and must never be read as free. Booking your own time emails nobody; inviting people emails everybody, and says so first. A recurring meeting makes it ask which you meant, and it will not guess.
The surface
What AI calendar scheduling can actually do
Start with the boundary, because it decides whether the rest of this page is for you. The calendar tools work on a mailbox that has a diary connected, and connecting a mailbox does not connect one. There are three routes to it: calendar access approved on a Microsoft 365 sign-in, a Google sign-in for a Google calendar, or the address of a CalDAV calendar server, and the last two work on any mailbox whoever hosts the mail. A mailbox with none of them is handed none of these tools. Not tools that answer "this mailbox has no calendar" - no tools at all, so your assistant never offers something that was going to fail. Which route is yours, and what each one gets you, is its own guide.
Within that, the surface is the one a person actually uses. Reading the diary between two dates. Searching it by subject, location or organiser. Opening one event with everybody invited and how each of them answered. Asking when a group of people are free, or asking Microsoft directly for the times a meeting would fit. Blocking your own time. Inviting people, rescheduling, cancelling, forwarding an invitation. Accepting, declining, or declining and proposing another time in the same breath. Setting your out-of-office reply for a date range. Snoozing a reminder. The full list is on the tool reference, with what each one refuses as well as what it does.
What I want to spend this page on is the four things that decide whether AI calendar scheduling is a good idea or a slow-motion accident, because each of them is invisible in a demo and obvious three weeks later in somebody else's meeting.
The one that matters
Free/busy, and why unknown is not free
There are two ways to find a time here, and they answer different questions. Asking who is free returns the raw availability and leaves the judgement to you. Asking Microsoft for meeting times hands the judgement over: it applies everybody's working hours and returns candidates ranked by how likely everyone is to make them. Both start in the same place.
When you ask when several people are free, what comes back is not their diaries. It is a list of blocks marked busy, free, tentative or out of office, one row per person, with no subjects and no attendees on them. That is the same information anybody in your organisation already sees when they open the scheduling assistant in Outlook, and it is a limit of what we ask Microsoft for rather than a filter applied afterwards.
The interesting part is the fourth answer. Sometimes a person's availability cannot be read at all: they are in a different organisation, or the sharing was never set up, or the address does not resolve. Microsoft does not fail the request when that happens. It returns 200 OK and marks that one attendee as unreadable inside an otherwise perfectly successful response. Every other name in the list comes back correctly. If you are writing the client and you are not looking for it, the natural shape of the code turns that person into an empty row, and an empty row is indistinguishable from a free afternoon.
Microsoft's own reference for its meeting-suggestion API is unusually frank about how much weight it puts on this, and the sentence is worth reading slowly:
For each attendee, a free status for a specified meeting time period corresponds to 100% chance of attendance, unknown status 49%, and busy status 0%.
Microsoft Learn, user: findMeetingTimes
Forty-nine per cent. Not zero, and not a hundred: a deliberate hair under a coin toss, so that an unreadable attendee drags a suggestion's confidence down without eliminating it, and so that a room full of unknowns can never quite reach the fifty per cent default. Microsoft has thought carefully about this and has still chosen to score it rather than refuse. That is the right call for a suggestion engine and it is a trap for anything reporting to a person, because a number that means "we do not know" and a number that means "probably fine" look identical once they have been through a language model and come out as a sentence.
So the rule here is a flat one. Where availability cannot be read, the answer is unknown, it is labelled unknown, and it is never rendered as free. The tool descriptions say it, the results say it, and the wording is deliberately blunt because it has to survive being summarised. If you take one thing from this page into your evaluation of any scheduling integration, make it this: ask what it does with somebody it cannot see, and be suspicious of any answer that is not immediately specific.
Two different acts
Booking your own time, or inviting other people to a meeting
These feel like one operation and they are not, and every awkward outcome I have seen from calendar automation comes from treating them as one. Putting an hour in your own diary changes a row in a database that nobody else reads. Putting an hour in four people's diaries sends four emails, moves four other things, and cannot be quietly undone.
So they are separate tools with separate names, and the boundary between
them is enforced rather than documented. create_event blocks
your own time and sends nothing. schedule_meeting invites
people and says who will receive an invitation before it runs.
delete_event refuses outright the moment anybody else
is on the event, and names the tool that cancels a meeting
properly instead. That refusal exists for one failure mode: an event
vanishing from your calendar while four other people carry on holding the
time, which is worse than either deleting it properly or leaving it alone.
The same reasoning is why cancelling is one of only two calendar tools marked destructive. It emails everybody, and there is no version of it that does not.
Asking twice does not book twice
Every write carries an idempotency key derived from the request itself, so a conversation that stutters, retries, or asks for the same meeting a second way does not produce two meetings. This is the sort of thing nobody notices working and everybody notices failing, usually in front of the people who received both invitations.
Repeats
Recurring meetings, and the question it will always ask
A weekly stand-up is two objects wearing one name: the series, and each Tuesday it lands on. Outlook keeps them apart and asks you which you meant every time you move one, which is mildly annoying and entirely correct.
An assistant has the same choice and a much worse failure mode, because picking the series when you meant one occurrence rewrites a year of Tuesdays and nobody finds out until they turn up to a meeting that is no longer there. So there is no default. Changing an event that belongs to a series requires you to say whether you mean this occurrence or the whole series, and the tool refuses rather than choosing.
Reading follows the same principle. A repeating meeting comes back on every date it actually falls on, the way it appears in Outlook, rather than once as a recurrence rule somebody then has to interpret. A fortnight of a weekly meeting is two entries carrying the same series id, and the recurrence itself is described in words - "every week on Tuesday" - rather than handed over as a pattern object. Where the pattern is one this connector does not recognise, it says exactly that instead of picking the nearest thing it does know, which is the failure that produces confident wrong answers.
Time
Timezones, working hours and "three o'clock"
This is the part that sounds pedantic until the first time somebody answers from an airport. A time with no timezone on it is not a time, and a diary answer that omits one is wrong roughly twice a year even for people who never travel, because British Summer Time exists.
Every calendar answer comes back in the mailbox's own timezone and states it. That is not a formatting preference: it is why the calendar permission asks for mailbox settings as well as the calendar itself. Your timezone comes from that setting, and so do your working hours, and without working hours the phrase "tomorrow afternoon" cannot be turned into a range at all. Working hours are also what stop a suggested slot landing at seven in the evening on the grounds that your diary happened to be empty then.
One implementation detail is worth knowing if you are evaluating anything of this kind, because it is where I lost the most time building it. Microsoft's header for choosing a response timezone governs the response only. The two dates you send to bound the request are read as UTC regardless, so a client that sets the header and then passes local dates will silently lose events at both ends of the window. The fix here is unglamorous and reliable: pad the requested window generously either side, then filter what comes back against the local times you were actually asked about. Slightly more data over the wire, no timezone arithmetic of our own to be wrong about, and no events quietly missing from the edges of a day.
Consent
Which calendar tools your AI client stops on
Every tool this server publishes carries an annotation saying what running it would do: read only, a change you can put back, or something irreversible or outward-facing. Your AI client reads those and decides whether to run a tool quietly or stop and ask you first. It is the same mechanism described on the tool reference, and the calendar tools use it exactly as the mail tools do.
The line falls in a slightly different place here, which is worth understanding rather than memorising. Booking a meeting is marked reversible even though it emails people, because cancelling it reaches everybody the invitation did. Only two are destructive: deleting an event, and cancelling a meeting. That is a judgement about what can be taken back rather than about what feels significant, and it is the judgement the protocol asks a server to make.
What the protocol will not do is make that decision for your client. Its specification is direct about where the responsibility sits:
For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.
Model Context Protocol specification, Tools
Note the word: should, not must. The specification is describing what a well-behaved client ought to do, and clients differ in how strictly they apply it. So the annotation is the fact and your own client's behaviour is the thing to check, in the same way that its connector settings rather than our list decide whether it can reach a remote server at all. Before you let anything invite people on your behalf, run one meeting through it and watch whether your client actually stops.
There is a second reason to care about that, and it is not about mistakes. Simon Willison's name for the combination is worth borrowing:
Access to your private data... Exposure to untrusted content... The ability to externally communicate in a way that could be used to steal your data.
Simon Willison, The lethal trifecta for AI agents
A calendar assistant has all three by design, which is not a reason to avoid one but is a reason to know what you are holding. Your diary and your mail are the private data. An event body, a meeting subject and an invitation from a stranger are text somebody else wrote, which makes them untrusted content in exactly Willison's sense. And sending mail is the external channel. That is why every piece of third-party text this server returns is fenced before a model sees it, and why the security page has a section on the email itself being the attack rather than a badge.
Providers
Which calendars it reaches, and how each one connects
Connecting a mailbox does not connect a diary, because they are separate services with separate credentials. There are three ways to connect one, and which is yours is decided by where the diary lives rather than by where the mail lives.
Microsoft 365 does it in the same sign-in. Approve calendar access when you connect the mailbox and every tool on this page is there. A mailbox connected before calendar access existed keeps working for mail and gains the diary when its owner signs in again; Microsoft does not widen a permission already granted, so nothing is wrong with the connection and it simply has to be asked again.
Every other mailbox does it with an address. IMAP is a mail protocol and there is no calendar inside it, at any host, so connecting the mail cannot connect the diary. What most hosts run alongside it is a calendar server speaking CalDAV, and giving us its address is what makes the calendar tools appear. Fastmail, iCloud and Nextcloud all run one, and on Fastmail and iCloud the same app password opens the mail and the diary, so it is usually one field.
What you get from a CalDAV calendar depends on the server, so it is asked rather than assumed. No two are quite alike: one will send invitations to other people and answer who is free, another only stores events. The account is opened before anything is saved, and the answer decides which tools are registered, so what your client is offered is what will work on your calendar rather than a list that hopes.
Google Calendar is a sign-in of its own, on any mailbox. The app password a Gmail mailbox connects with is a mail credential: it opens IMAP and SMTP and nothing else, and Google refuses it on its own CalDAV endpoint too, so the address route above was never going to rescue this one. What reaches a Google diary is a Google permission, which is why it is a button rather than a field. It covers the diary and never the mail, and the Google account does not have to be the address the mailbox is on.
Three of the tools on this page have no Google equivalent and are absent on that route rather than offered and failing: declining with a counter-proposal, forwarding an invitation, and the out-of-office. The last is the one to know about, because Google Calendar has an out-of-office event and it declines meetings without emailing anybody, which is not the automatic reply you would be asking for. The guide to connecting a calendar covers all three routes and what each one gets you.
Limits
What AI calendar scheduling will not do
-
A calendar has to be connected separately
Calendar tools appear once a diary is connected, which is its own step: calendar access approved on a Microsoft 365 sign-in, a Google sign-in for Google Calendar, or the address of a CalDAV calendar server. A mailbox with none of the three gets the email tools and no calendar tools at all.
-
Unknown is not free
When somebody's calendar cannot be read, the answer is unknown rather than free. Free/busy across organisations depends on an arrangement between them, and a name that comes back blank has told you nothing.
-
A calendar search needs dates
Reading or searching the diary needs a start and an end. A diary has no end, so there is no "everything" to return, and the answer always names the window it looked in.
-
No room browsing
It cannot list the meeting rooms an organisation has. Reading a room directory needs a permission only an IT administrator can approve, and asking every customer for that to power one convenience is the wrong trade. A room with an email address can still be invited and its free/busy checked, exactly like a person.
-
No files on calendar events
Files attached to a calendar event are not read or written yet. Attachments on email are, and event attachments are a separate piece of work rather than an oversight.
-
Nothing is scheduled
It cannot schedule a send. Everything happens when you ask for it, and nothing runs while you are away.
-
It is not an assistant that watches
Nothing runs while you are away. There is no rule engine and no background process reading your diary, so a meeting is only ever rearranged because you asked in a conversation. Setting an out-of-office reply for a future date range is not an exception: Microsoft applies that setting at the time, exactly as it would if you had ticked the box in Outlook yourself.
Can an AI book meetings in my calendar?
Yes, once a calendar is connected. On a Microsoft 365 mailbox whose owner approved calendar access it can block time in your own diary, invite people to a meeting with an online link, reschedule one and tell everybody, cancel one with a message, and answer an invitation you have been sent. A Google calendar gets the reading, the free/busy, the booking, the meetings and the answering, on whatever the customer left ticked at the consent screen. Any other calendar gets the same surface as far as its CalDAV server supports it, which is asked when the calendar connects rather than assumed. Every tool that will email somebody says so before it runs, and your AI client stops to ask. A mailbox with no calendar connected gets none of these: it is handed no calendar tools at all rather than tools that would refuse.
Will it book a meeting over something I am already doing?
Not on the strength of an answer it could not read, which is the failure worth worrying about rather than the obvious one. It reads free/busy for everybody you name, and where somebody cannot be seen - a different organisation, or permission never granted - that person comes back as unknown, never as free. Microsoft reports those one attendee at a time inside an otherwise successful response, so an integration that treats a blank as an empty afternoon looks like it is working right up until the meeting lands in the middle of somebody's day.
Does it work with Google Calendar?
Yes, on any mailbox, whoever hosts the mail. It takes a Google sign-in of its own rather than arriving with the mail, because the app password a Gmail mailbox connects with is a mail credential: it opens IMAP and SMTP and nothing else, and Google refuses it on its own CalDAV endpoint too. So it is one button and one consent screen, and the Google account does not have to be the address the mailbox is on. Three things Outlook does have no Google equivalent and are absent rather than offered and refused: declining with a counter-proposal the organiser can accept, forwarding an invitation, and setting an out-of-office. Every other calendar with a CalDAV address works too, on any mailbox: Fastmail, iCloud, Nextcloud and most mail hosts run one.
Which calendar tools will send an email to somebody else?
Inviting people to a meeting, changing one they are on, cancelling one, forwarding an invitation, and answering an invitation when you choose to tell the organiser. Those all put a real message in somebody's inbox from your address. Blocking time in your own diary sends nothing, and neither does reading, searching or checking availability. The tool that deletes an event refuses outright the moment anybody else is invited, and names the cancel tool instead, so an invitation is never quietly removed from your own calendar while everybody else keeps holding the time.
Will it change every week of a recurring meeting if I only meant one?
Not by guessing, because it is not allowed to guess. A repeating meeting is two things at once, the series and each date it lands on, and Outlook keeps them apart. Changing an event that belongs to a series requires you to say which of the two you meant, and there is no default that quietly picks one. Reading the diary shows a repeating meeting on every date it actually falls on, the way Outlook does, with the id of the series attached to each.
What timezone does it answer in?
Your mailbox's own, which is a setting in Microsoft 365 rather than something we choose, and every answer states it rather than leaving you to assume. That is why the calendar permission includes mailbox settings: without your timezone a time cannot be stated correctly, and without your working hours "tomorrow afternoon" cannot be turned into anything. Working hours are also what stop a suggested slot landing at seven in the evening merely because the diary was empty then.
Do calendar calls come out of a separate allowance?
No. They are metered exactly like the mail tools, out of the same daily allowance on the same mailbox, and there is nothing extra to buy. Checking when four people are free, booking the meeting and sending the invitations is three calls. Free is 5 calls a day per mailbox and Pro is 1,000, both published ceilings.
Attribution
Sources
- Microsoft Learn: user: findMeetingTimes The confidence arithmetic quoted above, including the 49% an unknown attendee scores, and the working-hours rules that decide which slots are suggested. Read 2 September 2026.
- Microsoft Learn: calendar: getSchedule The free/busy call itself: what it returns per person, and its note that a calendar with more than 1,000 entries in the window comes back as a 5006 rather than as a failed request. Read 2 September 2026.
- Model Context Protocol specification: Tools The human-in-the-loop guidance quoted above, and the tool annotations a client reads to decide what to ask you about. Read 2 September 2026.
- Simon Willison: The lethal trifecta for AI agents The three capabilities that make an agent worth thinking carefully about, quoted above. Read 2 September 2026.
- The calendar tools behind everything on this page Each one with what it does and where it refuses, taken from the server's own registration code.
Keep going
Read next
Ask it what you have on Thursday.
One call, in your own timezone, with the repeats where they belong. That is the cheapest honest test of AI calendar scheduling there is, and it tells you in a minute whether you trust it with the invitations.