Letting an AI book meetings on a calendar you actually keep.

There are 2 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 ranks the candidates by how likely everyone is to make them.

Both start in the same place. Ask when several people are free and you don't get their diaries. You get blocks marked busy, free, tentative or out of office, one row per person, with no subjects and no attendees on them.

That's what anybody in your organisation already sees in Outlook's scheduling assistant. It's a limit of what we ask Microsoft for, not a filter applied afterwards.

The fourth answer: unknown

Sometimes a person's availability can't be read at all. They're in a different organisation, or the sharing was never set up, or the address doesn't resolve.

Microsoft doesn't 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're writing the client and not looking for it, the natural shape of the code turns that person into an empty row. And an empty row looks exactly like a free afternoon.

Microsoft's own reference for its meeting-suggestion API is unusually frank about how much weight it gives this. 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

49 per cent: not zero, and not a hundred. It's a deliberate hair under a coin toss. An unreadable attendee drags a suggestion's confidence down without ruling it out, and a room full of unknowns can never quite reach the 50 per cent default.

Microsoft has thought carefully about this and still chose to score it rather than refuse. That's the right call for a suggestion engine. It's a trap for anything reporting to a person, because "we don't know" and "probably fine" look identical once a language model has turned them into a sentence.

So the rule here is flat. Where availability can't be read, the answer is unknown, it's labelled unknown, and it's never shown as free. The tool descriptions say it and the results say it, in deliberately blunt words, because they have to survive being summarised.

If you take one thing from this page into your evaluation of any scheduling tool, make it this. Ask what it does with somebody it can't see, and be suspicious of any answer that isn't immediately specific.

A weekly stand-up is 2 things wearing one name: the series, and each Tuesday it lands on. Outlook keeps them apart and asks which you meant every time you move one. That's mildly annoying, and entirely correct.

An assistant has the same choice and a much worse way to fail. Pick the series when you meant one occurrence and it rewrites a year of Tuesdays. Nobody finds out until they turn up to a meeting that's no longer there.

So there's no default. To change an event that belongs to a series, you say whether you mean this occurrence or the whole series, and the tool refuses rather than choosing.

Reading follows the same rule. A repeating meeting comes back on every date it actually falls on, the way it appears in Outlook, not once as a recurrence rule somebody then has to interpret. A fortnight of a weekly meeting is 2 entries carrying the same series id.

The repeat itself is described in words, "every week on Tuesday", rather than handed over as a pattern object. Where the pattern is one this connector doesn't recognise, it says exactly that. It never picks the nearest thing it does know, which is how confident wrong answers get made.

Every tool this server publishes carries a label 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 labels (annotations, in the protocol's terms) and decides whether to run a tool quietly or stop and ask you first.

It's the same mechanism described on the tool reference, and the calendar tools use it exactly as the mail tools do.

Everything that emails another person is marked destructive

That's inviting, rescheduling, cancelling, forwarding an invitation, answering one, proposing another time, and setting an out-of-office reply. Deleting an event is destructive too, for the older reason that it can't be taken back.

Blocking your own time, changing it and reading the diary stay reversible or read-only. That's a judgement about what can be recalled, not about what feels significant, and it's the judgement the protocol asks a server to make.

The line is worth understanding, because it moved. Until 12 September 2026, booking a meeting was marked reversible even though it emails people, on the argument that cancelling it reaches everybody the invitation did.

That argument was wrong about the thing that matters. The invitation has still been read, in somebody else's inbox, in your name, and no cancellation unreads it.

Your client decides whether to stop

What the protocol won't 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 describes what a well-behaved client ought to do, and clients differ in how strictly they apply it.

So the label is the fact, and your own client's behaviour is the thing to check, just as its connector settings, not our list, decide whether it can reach a remote server at all. Before you let anything invite people for you, run one meeting through it and watch whether your client actually stops.

Private data, untrusted text, and a way out

There's a second reason to care, and it isn't 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 3 by design. That isn't a reason to avoid one, but it is a reason to know what you're holding.

Your diary and your mail are the private data. An event body, a meeting subject or an invitation from a stranger is text somebody else wrote, which makes it untrusted content in exactly Willison's sense. And sending mail is the external channel.

That's why every piece of third-party text this server returns is fenced off before a model sees it. It's also why the security page has a section on the email itself being the attack, rather than a badge.