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 3 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 2
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, not 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 3 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 3, and it's the part people brace for: the calendar attaches to a mailbox you've already connected. There's 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's already there.
Route one
Microsoft 365: the tick box on the sign-in you already do
This is the easy one. When you connect a Microsoft 365 mailbox you're shown a list of permissions, and 2 of them are the calendar ones. Approve, and the mailbox arrives with its diary already attached.
It's 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 isn't a convenience we bolted on.
One case looks like a fault and isn't: a mailbox connected before the calendar permissions existed can't grow them on its own. Microsoft doesn't 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's 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 2 permissions cover and the 2 things that work there and nowhere else.
Route 2
Google Calendar: one sign-in, on any mailbox
It doesn't need a Gmail mailbox: your mail can be anywhere. Press Connect Google Calendar, choose an account, and approve what Google shows you.
This is the route most people arrive looking for. 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's the whole setup.
Why it's a button, not a field
The obvious workaround doesn't work, and it's 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's safe to hand over.
Google also runs a CalDAV endpoint, the same protocol route 3 uses. It refuses that app password too. There was never an address to paste that would have worked, so the sign-in isn't a second hurdle anybody invented.
What the permission covers, and what it does not
3 permissions, and all 3 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 touches Drive, contacts or anything else in the account.
You can withdraw the lot from your Google account whenever you like. Disconnecting the calendar here hands the permission back, rather than leaving it sitting on your account page for years.
The Google account doesn't 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, not a fortnight later when a meeting fails to appear.
The 3 things Google has no equivalent of
These are absent on this route rather than offered and refused. That's 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 didn't buy.
-
Declining with a counter-proposal.
In Outlook that's 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 don't organise it's frequently refused outright.
Different behaviour wearing the same name is worse than a missing tool.
-
The out-of-office, which is the one most worth knowing
about.
Google Calendar does have something called an out-of-office event, and it isn't what anybody assumes. Its properties are an auto-decline mode and a decline message: it turns down meetings and it emails nobody.
The real equivalent of an Outlook automatic reply is Gmail's vacation responder. That's a mail setting, behind a Google mail permission this connection doesn't hold and doesn't 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.
If you untick a box
If you untick a box on Google's consent screen, the tools that needed it are absent afterwards, not 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 3
Every other calendar: an address, and where to find it
IMAP is a mail protocol, and there's no diary inside it, at any host. That's where most integrations stop, and it's 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. Giving us that address is the whole job.
It's filed under calendar sharing or CalDAV rather than under anything with the plain word calendar on it, which is why it feels hidden. The CalDAV and CardDAV page has the addresses for Fastmail, iCloud, Nextcloud, StackMail and Zoho, the app password each one wants, and the address book that usually lives on the same server.
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.
You paste it in and we open the account while you wait. If it opens, the calendar tools appear and you're told what that particular server turned out to support.
If it doesn't open, nothing is stored, and you're told which of the address and the password was refused. That's the difference between a 2-minute fix and an afternoon.
The part nobody tells you
Why 2 people with CalDAV get different tools
2 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 isn't 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 5 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's the worst kind of failure available here, because it's invisible from both ends: you think you invited them, and they never heard from you.
So we don't guess, and we don't 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's 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, not a server's capabilities, because Google implements all of it. But a permission isn't the same thing as being allowed to write, and treating them as one 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's a smaller trap next to it, worth publishing because it's so easy
to get wrong. Google's calendar list reports an access role per calendar,
and the documented set has 5 values, not the 4 the names
suggest: freeBusyReader, reader,
writerWithoutPrivateAccess, writer and
owner.
The third one reads and writes; what it can't 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, not an error. Nobody reports a missing tool. They just conclude it can't 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 don't add a second connector, you don't sign in again in your AI client, and there's 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 don't appear straight away, removing and re-adding that connector, or restarting the client, is the usual fix. That's your client's behaviour, not ours, and it's worth trying before assuming the calendar didn't 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.
If the calendar stops opening
A calendar credential can die without anything on your side changing. Google withdraws a permission when the account password changes, when Mailbox MCP is removed from the account's connected apps, or when the permission goes unused for 6 months.
A calendar server refuses an app password the moment it's withdrawn, and an app password is withdrawn without the mail password changing. When that happens the mail keeps working and the calendar tools go: your assistant simply stops offering them on that mailbox.
Since 12 September 2026 you're told, in 3 places:
- the mailbox row in the control panel gains a Reconnect calendar mark under its connection state, which stays green because the mail is fine
- the overview lists the calendar under what needs your attention
- you get one email, naming the mailbox, the account or server, what the provider said, and since when
The fix is on the mailbox's own page. Sign in with Google again on a Google calendar, or enter the current sign-in details on a CalDAV one. On Microsoft 365, re-authorise the mailbox, where the diary and the mail share a permission and go together.
You can turn the email off under alerts in your account settings; the panel marks stay regardless.
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 3 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.
-
Contacts are looked up, never copied
Your address book stays where it is.
Where the mailbox has one (its Outlook contacts on a Microsoft 365 sign-in; on a mailbox that uses a password, your Google contacts by a Google sign-in of their own, or a CardDAV book you connect by its address), a person is looked up in it when you ask, held in memory for about 10 minutes, and forgotten: nothing about a contact is written to a database, a file or a log of ours.
On a mailbox with no book, addresses are resolved from the mailbox's own history. There is no file store either: an attachment is read and sent on the message it belongs to rather than kept anywhere as a document of its own.
-
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 the diary: they are separate services, and connecting one never connects the other. Which route is yours depends on where the diary lives. A Microsoft 365 mailbox is asked for calendar access on the same sign-in as the mail. 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. The tools then appear on the connector already in your AI client.
Can I connect Google Calendar?
Yes, on any mailbox, whoever hosts the mail. It is a Google sign-in, not a password you paste: an app password opens IMAP and SMTP and nothing else, and Google refuses one on its own CalDAV endpoint too. You press Connect Google Calendar, choose an account, and Google shows what is being asked for. It covers the diary and never the mail, the account need not match the mailbox, and you can withdraw it at any time.
Where do I find my CalDAV address?
In your provider's help pages, usually filed under calendar sharing or CalDAV. The addresses Fastmail, iCloud, Nextcloud, StackMail and Zoho publish, and the app password each wants, are on the CalDAV and CardDAV connect page at https://mailbox-mcp.com/connect/caldav/. Paste it in and the panel opens the account while you wait. If it opens, it tells you what that server supports; if not, nothing is stored and it tells you whether the address or 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 2 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 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. So the server is asked what it implements when it connects, and only those tools 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, 5 years later, defining the separate "calendar-auto-schedule" feature. The gap between these 2 documents is why a CalDAV server has to be asked what it implements. Read 3 September 2026.
- Google Calendar API: CalendarList reference The 5 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.