Guide
Connecting a calendar, on whichever route is yours.
Connecting a mailbox does not connect a diary, because they are separate services with separate credentials. There are three ways to connect one and they do not behave alike: one is a tick box on a sign-in you are already doing, one is a sign-in of its own, and one is an address whose capabilities have to be measured rather than assumed. This is how to tell which is yours.
- Reading About 11 minutes
- Routes Microsoft 365, Google or CalDAV
- Time to do A minute or two
The short version
Connect the mailbox first, then the diary, because one never brings the other. Microsoft 365 asks for the calendar on the same sign-in as the mail. Google Calendar takes a sign-in of its own, on any mailbox, and the Google account need not be the mailbox address. Everything else connects with the address of a CalDAV calendar server, and what that gets you is decided by the server rather than by us. The tools then appear on the connector already in your AI client. Nothing extra to install, nothing extra to pay.
The decision
Which of the three calendar routes is yours
The question that decides it is where the diary lives, not where the mail lives, and those are more often different than people expect. A Gmail mailbox with a Fastmail diary is an ordinary arrangement. So is a personal Google calendar beside a mailbox on a company domain. Pick the row that describes the calendar you actually look at in the morning.
| Microsoft 365 | Google Calendar | Any CalDAV calendar | |
|---|---|---|---|
| Which mailboxes | Microsoft 365 mailboxes only | Any mailbox, whoever hosts the mail | Any mailbox, whoever hosts the mail |
| What you do | Tick the calendar permission on the Microsoft sign-in | Press a button and choose a Google account | Paste the address of your calendar server |
| What you need to hand | Nothing beyond the sign-in itself | Nothing. No app password, no address | The server address, and often the same password as the mail |
| Must it match the mailbox? | Yes. It arrives on the mailbox sign-in | No. Any Google account you choose | No. The address and its password are given separately |
| What you get | Every calendar tool, including the out-of-office | Reading, free/busy, booking, meetings and answering invitations | Whatever that server turns out to implement, measured when it connects |
One thing is the same on all three, and it is the part people brace for: the calendar attaches to a mailbox you have already connected. There is no second account, no second connector to add in your AI client, and nothing extra to pay. The tools simply appear on the connection that is already there.
Route one
Microsoft 365: the tick box on the sign-in you already do
This is the easy one, and it is easy for a real reason rather than a lucky one: Microsoft Graph is a single API over the mail and the diary, so approving both on one screen is not a convenience we bolted on. When you connect a Microsoft 365 mailbox you are shown a list of permissions and two of them are the calendar ones. Approve, and the mailbox arrives with its diary already attached.
There is one case worth knowing about, because it looks like a fault and is not. A mailbox connected before the calendar permissions existed cannot grow them on its own. Microsoft does not widen a grant that has already been given, so however correct that connection is, it can never mint a calendar token. Nothing is broken and there is nothing to repair: the mailbox keeps working for mail, and signing in again is what adds the diary. The control panel offers that where the fix actually lives.
The full Microsoft 365 calendar section covers what the two permissions cover and the two things that work there and nowhere else.
Route two
Google Calendar: one sign-in, on any mailbox
This is the route most people arrive looking for, and the first thing to say is that it does not require a Gmail mailbox. Your mail can be anywhere. You press Connect Google Calendar in the control panel, choose an account, and Google shows you exactly what is being asked for before you approve anything. That is the whole setup.
It is worth explaining why this one is a button rather than a field, because the obvious workaround does not work and it is better to say so than to let somebody spend an evening on it. An app password of the kind a Gmail mailbox connects with is a mail credential: it opens IMAP and SMTP and nothing else, which is precisely why it is safe to hand over. Google also runs a CalDAV endpoint, the same protocol route three uses. It refuses that app password too. There was never an address to paste that would have worked, so the sign-in is not a second hurdle anybody invented.
What the permission covers, and what it does not
Three permissions, and all three are about the diary. One lists which calendars the account has, one reads free and busy time, and one reads and writes events. None of them touches the mail, and none of them touches Drive, contacts or anything else in the account. You can withdraw the lot from your Google account whenever you like, and disconnecting the calendar here hands the permission back rather than leaving it sitting on your account page for years.
The Google account does not have to match the mailbox address. This matters more often than it sounds. The panel shows you which account the calendar came back as, so picking the wrong one in Google's chooser is something you notice in the same minute rather than a fortnight later when a meeting fails to appear.
One thing to expect while it is in front of you. Our Google verification is submitted and under review, so Google currently shows a screen saying it has not verified this app, with the way past it behind the Advanced link. That screen is about our review status rather than about what the permission does.
The three things Google has no equivalent of
These are absent on this route rather than offered and refused, which is the rule the whole product follows: a tool certain to fail still spends one of your metered calls to say so, still invites the model to try again a different way, and still advertises something you did not buy.
Declining with a counter-proposal. In Outlook that is a structured message the organiser can accept or reject. Google has no public API for one, and emailing the organiser instead would have an assistant confidently report a proposal that nobody will ever see. Forwarding an invitation. Adding somebody to the attendee list on Google is a different act with different consequences: it makes you appear to have invited them, and on an event you do not organise it is frequently refused outright. Different behaviour wearing the same name is worse than a missing tool.
And the out-of-office, which is the one most worth knowing about, because Google Calendar does have something called an out-of-office event and it is not what anybody assumes. Its properties are an auto-decline mode and a decline message: it turns down meetings and it emails nobody. The actual equivalent of an Outlook automatic reply is Gmail's vacation responder, which is a mail setting behind a Google mail permission this connection does not hold and does not ask for. An assistant that quietly created a calendar event when you asked for an out-of-office would leave you looking rude to everybody who wrote while you were away, and neither you nor we would ever see it happen.
One last case to expect: if you untick a box on Google's consent screen, the tools that needed it are absent afterwards rather than present and failing. The panel lists what you actually got. If something you wanted is missing, connect the calendar again and leave everything ticked.
Connecting a Google diary is one button and one consent screen, and the free tier of 5 calls a day is enough to ask what you have on Thursday.
Route three
Every other calendar: an address, and where to find it
IMAP is a mail protocol and there is no diary inside it, at any host. That is where most integrations stop, and it is why an assistant connected to an ordinary mailbox can usually read your week only by reading emails about it. What most hosts run alongside the mail server is a calendar server speaking CalDAV, with an address of its own, and giving us that address is the whole job.
It is filed under calendar sharing or CalDAV rather than under anything with the plain word calendar on it, which is why it feels hidden. Fastmail publishes a per-account URL in its settings. iCloud uses the same app-specific password as the mail, so it is usually one field. Nextcloud shows the address on the calendar page behind the settings cog. If your mail is with your web host or your domain registrar, the calendar server is very often the same hostname with the word calendar in front of it.
You paste it in and we open the account while you wait. If it opens, the calendar tools appear and you are told what that particular server turned out to support. If it does not open, nothing is stored and you are told which of the address and the password was refused, which is the difference between a two-minute fix and an afternoon.
The part nobody tells you
Why two people with CalDAV get different tools
Two customers can connect the same protocol, on the same day, and be offered different lists. Both are correct, and the reason is written into the standard rather than into anybody's product.
CalDAV is not one specification. RFC 4791, published in March 2007, defines the "calendar-access" feature: a standard way of accessing, managing and sharing calendaring information. It says nothing at all about sending an invitation to another human being. Scheduling arrived five years later, in RFC 6638 of June 2012, as a separate feature called "calendar-auto-schedule", and plenty of servers in daily use never followed.
That gap has a nasty shape. A server that implements only the first will accept a meeting with people invited, store it, answer that it worked, and tell nobody. The event sits in your diary looking correct. No invitation was ever sent. It is the worst kind of failure available here, because it is invisible from both ends: you think you invited them and they never heard from you.
So we do not guess and we do not offer a hopeful list. The server is asked what it implements at the moment it connects, and your assistant is handed only the tools it actually answered for. A store-only calendar gets reading, searching and your own time. One that implements scheduling gets the meeting tools as well. The control panel shows you the list your particular server gave, so it is checkable rather than promised.
Google settles it differently, and there is a trap in that too
On Google the list follows the permissions you approved rather than a server's capabilities, because Google implements all of it. But a permission is not the same thing as being allowed to write, and conflating the two would quietly withdraw tools from ordinary people. Somebody whose only calendars are subscribed read-only feeds, a colleague's diary or a holiday calendar, has granted everything and can still write nothing.
There is a smaller trap sitting next to it that is worth publishing
because it is so easy to get wrong. Google's calendar list reports an
access role per calendar, and the documented set has
five values, not the four the names suggest:
freeBusyReader, reader,
writerWithoutPrivateAccess, writer and
owner. The third one reads and writes; what it
cannot do is see the details of events marked private. Treating it as a
reader would silently remove every write tool from anybody whose diary is
a calendar shared with them that way, which is an everyday arrangement
inside an organisation, and the symptom would be a missing tool rather
than an error. Nobody reports a missing tool. They just conclude it cannot
do it.
Afterwards
What changes in your AI client once it connects
Less than people expect, which is the point. When you connect your calendar the tools appear on the connector you already added. You do not add a second connector, you do not sign in again in your AI client, and there is nothing new to pay for. Ask what you have on Thursday and it answers.
One practical wrinkle: some AI clients cache the tool list they were given when the connector was added. If the calendar tools do not appear straight away, removing and re-adding that connector, or restarting the client, is the usual fix. That is your client's behaviour rather than ours, and it is worth trying before assuming the calendar did not connect.
Calendar calls are metered exactly like the mail ones, out of the same allowance rather than a separate one. And the tools that will email somebody say so before they run, so your client can stop and ask. Which ones those are, and the one answer you must never let it round in your favour, is the guide to read next.
Whichever route is yours, the diary attaches to a mailbox you have already connected, so trying it costs a sign-in and no card.
Limits
What connecting a calendar does 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.
-
No contacts, no files
It does not manage a contacts list or a file store. Addresses are resolved from the mailbox's own history rather than from an address book, and attachments are handled as mail rather than as documents.
-
One diary a mailbox
A mailbox carries one calendar connection. Where that connection reaches several calendars, as a Google account usually does, all of them are available through it. What you cannot do is attach a Google diary and a CalDAV one to the same mailbox at once.
-
It does not move your diary
Connecting a calendar reads and writes the one you already keep, in the place you already keep it. Nothing is copied here, nothing is synchronised into a second calendar, and disconnecting changes nothing in the diary itself.
How do I connect my calendar to an AI assistant?
Connect the mailbox first, then connect the diary, because they are separate services and connecting one never connects the other. Which route is yours is decided by where the diary lives rather than by where the mail lives. A Microsoft 365 mailbox is asked for calendar access on the same sign-in as the mail, so there is a tick box and nothing else to find. A Google diary takes a Google sign-in of its own, on any mailbox. Anything else connects with the address of a CalDAV calendar server, which Fastmail, iCloud, Nextcloud and most mail hosts run. The calendar tools then appear on the connector you already set up in your AI client, which does not need changing.
Can I connect Google Calendar?
Yes, on any mailbox, whoever hosts the mail. It is a Google sign-in rather than a password you paste, and that is not a hurdle we invented: an app password is a mail credential that opens IMAP and SMTP and nothing else, and Google refuses one on its own CalDAV endpoint too, so there was never an address that would have worked. You press Connect Google Calendar, choose an account, and Google shows what is being asked for before you approve it. It covers the diary and never the mail, the account does not have to match the mailbox address, and you can withdraw it from your Google account at any time.
Where do I find my CalDAV address?
In your provider's help pages, usually filed under calendar sharing or CalDAV rather than under anything with the word calendar on its own. Fastmail publishes it as a per-account URL, iCloud uses the same app-specific password as the mail, and Nextcloud shows it on the calendar page behind the settings cog. If your mail is hosted with your domain registrar or web host, the calendar server is normally the same hostname with calendar in front of it. Paste it in and the panel opens the account while you wait: if it opens, you are connected and it tells you what that server turned out to support, and if it does not, nothing is stored and it tells you which of the address and the password was refused.
Do I need a second connector in my AI client?
No, and this is the part people expect to be harder than it is. A calendar attaches to a mailbox you have already connected, so the tools appear on the connector that is already in your client. There is nothing to add, nothing to reconfigure and nothing extra to pay. Some clients cache the tool list, so if the new tools do not appear straight away, reconnecting that connector is the usual fix.
Why do two people with CalDAV calendars get different tools?
Because their servers implement different things and we ask rather than assume. RFC 4791 defines a store for calendar entries and says nothing at all about sending an invitation; RFC 6638 added that years later and plenty of servers never followed. A server without it will accept a meeting with people invited, answer that it worked, and tell nobody, which is the worst kind of failure because it is invisible from both ends. So the server is asked what it implements at the moment it connects, and only the tools it answered for are registered.
Can I connect a calendar that is not on the same account as the mail?
Yes on the Google route, where the account you sign in with is whatever you choose and is shown back to you afterwards so a wrong choice is obvious immediately. Yes on the CalDAV route too, since the address and its credentials are given separately from the mail ones. Microsoft 365 is the one case where they are necessarily the same, because the calendar arrives on the mailbox sign-in itself.
What happens to the calendar tools if I disconnect the diary?
They go, and the mail carries on untouched. The same is true if a calendar simply stops opening: a diary that will not connect never takes the mailbox down with it, because losing every mail tool over a feature you added as an extra would be the wrong failure. In both cases the tools are absent rather than present and refusing, which is the same answer your client gets for a mailbox that never had a calendar.
Attribution
Sources
- RFC 4791: Calendaring Extensions to WebDAV (CalDAV) The store half of the protocol, March 2007. Its abstract defines the "calendar-access" feature and describes accessing, managing and sharing calendaring information, with no mention of scheduling. Read 3 September 2026.
- RFC 6638: Scheduling Extensions to CalDAV The scheduling half, June 2012, five years later, defining the separate "calendar-auto-schedule" feature. The gap between these two documents is why a CalDAV server has to be asked what it implements. Read 3 September 2026.
- Google Calendar API: CalendarList reference The five documented access roles quoted above, including writerWithoutPrivateAccess, which the reference describes as providing read and write access with the details of private events hidden. Read 3 September 2026.
- Google Calendar API: Events reference What a Google out-of-office event actually is: its outOfOfficeProperties carry an auto-decline mode and a decline message, which is a calendar behaviour rather than an email reply. Read 3 September 2026.
- The calendar tools a connected diary adds Each one with what it does and where it refuses, taken from the server's own registration code.
Keep going
Read next
Connect the mailbox, then the diary.
Both take about a minute, neither needs a card, and the second one attaches to the first. Then ask what you have on Thursday and see whether the answer is the one your own calendar would give.