Changelog: every release of the server, dated

2.7.3, 10 October 2026: our emails come from noreply@, and contacts are found by name and company

• Every email the service sends by itself, such as an address confirmation, a security notice or a getting-started note, now comes from noreply@mailbox-mcp.com. Where an email used to ask you to reply, it now says to write to support@mailbox-mcp.com, the inbox a person reads.
• If you've signed up and haven't added a mailbox yet, you now get 1 getting-started note, an hour after signing up, instead of 4. Once you add a mailbox, the notes about pointing your AI at it start as before, and each still has a one-click stop.
• Ask your AI to find someone by a first name and a company together, such as "Bob Acme", or by a name in either order, such as "Smith Bob", and find_contact now finds a contact whose name, email address or company holds every word, in any order. Before, the words had to sit side by side, in the order you typed them. A single word or an email address is looked up as before.

Unchanged: every tool name, parameter and result shape; the levels and the call allowance; the switches under Settings, What we email you about; and a reply from a person to a support request, which still comes from support@mailbox-mcp.com.

2.7.2, 10 October 2026: the note when a free mailbox runs out comes once, not once a day

• The note a free mailbox gets when it has used its 5 calls, saying when the first is back and what Pro costs, is now sent once for that mailbox, the first time, and not again. Before, it could come once a day.

Unchanged: every tool name, parameter and result shape; the call allowance itself, so a refused call still says when the next one frees up; the note's one-click stop; and the switch under Settings, What we email you about.

2.4.4, 6 October 2026: the connection test checks that search finds your mail

• When you add a mailbox, the connection test now also searches your inbox and checks the search finds the messages that are there. If your mail server answers with nothing, the test says so under the folders step and tells us automatically, so a fault like the one fixed in 2.4.3 shows up on the day you connect rather than weeks later.
• It only reads. Nothing is opened, moved or marked as read, and a mailbox is never turned away because of it: a search fault is ours to fix, not yours.

Unchanged: the other steps of the connection test, and what makes a mailbox pass or fail it.

2.4.3, 6 October 2026: searching a Strato mailbox finds your mail again

• On mailboxes hosted by Strato, every search came back empty. search_emails, select_emails, catch_up, waiting_on, owed_replies and check_upload all said nothing was found, even when the mail was right there. Reading, listing and sending worked normally.
• Strato's mail server answers searches with an empty result in the newer IMAP mode (IMAP4rev2). We now talk to Strato in IMAP4rev1, which it answers correctly, so searches find your mail again. There's nothing to reconnect.
• Every other mail provider connects exactly as it did before.

Unchanged: your connection, your password, and your folders and everything in them.

2.4.2, 6 October 2026: the sign-in pause after a wrong password now counts down

• After two wrong passwords, the sign-in page asks you to wait a moment before the next try. It's meant to be a second or two. Instead it kept asking for the same second on every try for up to 15 minutes, however long you'd waited, so it looked as if your account had stopped working.
• The pause now counts down from your last wrong password, so waiting the time it shows is enough.
• Setting a new password with a reset link now clears the pause too, so you can sign in with it straight away.

Unchanged: how long the pause is after each wrong password, your mailboxes and your connected AI.

2.4.1, 6 October 2026: the deliverability check no longer tells a Gmail user their DKIM is missing

• Asked whether a Gmail, Outlook.com, Hotmail or iCloud address is set up properly, your AI used to report that no DKIM key could be found for gmail.com (or outlook.com, or icloud.com). Nobody with one of those addresses can add a record there, and the provider signs its own mail.
• The check now says the domain belongs to Google, Microsoft, Apple or whichever provider it is, that the provider publishes and looks after SPF, DKIM and DMARC itself, and that there is nothing for you to set up. It still shows the provider's SPF and DMARC records as they stand.
• Your own domain is checked exactly as before.

Unchanged: every tool name, what each one does, and how your own domain is checked.

2.3.0, 5 October 2026: opening and forwarding attachments fails far less often

• When your AI reads an email, each attachment comes with a reference it passes back to open, forward or attach the file. That reference is now about half as long, so your AI copies it back correctly far more often. In some conversations about 1 in 4 attempts had been failing on a copying slip.
• Download links for attachments are shorter in the same way.
• Asking your AI what is in your calendar without saying when now works: it looks at the next 7 days, or 90 days either side of today for a search, and says which dates it checked.

Unchanged: every tool name and what each one does. References and links handed out before the update keep working until they expire.

2.2.0, 4 October 2026: clear out senders in a few calls

• Your AI can now pick out up to 500 emails in one go, from one sender or up to 20, by subject, by date, or a whole folder, and delete, file or mark them in the next. 1,000 emails from one sender is about 4 calls rather than about 20.
• Before it acts, it can tell you who they are from, how many, how many are unread or flagged, and the dates. Deleted mail still goes to Trash, as in Outlook.
• When your AI changes a repeating calendar event, it now says plainly that a date you had already changed on its own may keep its own details, and it no longer says "every date" about an event that does not repeat.

Unchanged: every existing tool, the levels, the call allowance, and what a search returns.

2.1.2, 4 October 2026: calendar changes over CalDAV now do exactly what they say

• On a calendar connected over CalDAV, moving or renaming one date of a repeating event now changes that date only. Before, it could change every date in the series, and for a meeting, tell everyone invited.
• Asking your AI to change only an event's reminder now changes it. Before, it said the event was updated and kept the old reminder. Any other alerts on the event, such as an email the day before, are left as they are.
• An update that names nothing to change is refused, as it already was on Microsoft 365 and Google. On a meeting, such an update could send everyone invited an update notice for nothing.
• An event marked confidential is saved as confidential. Before, it was saved as public.

Unchanged: every tool name, parameter and result shape. Microsoft 365 and Google calendars, which already worked this way.

2.1.1, 4 October 2026: a plain answer when Outlook.com has IMAP off, and fewer refused calls

• If your Outlook.com or Hotmail account has IMAP switched off, your AI now tells you so and where the switch is: Settings, Mail, Forwarding and IMAP, "Let devices and apps use IMAP". Before, it could only repeat Microsoft's own words, which don't say what to do. It also says when Microsoft is only refusing for a minute, so it's worth trying again shortly.
• When your AI tries to open a draft you've since saved again in Outlook or Apple Mail, which gives it a new place in Drafts, it's shown your newest drafts so it can open the right one, rather than stopping at "not found".
• Some AI apps send a blank setting as null, or write a number in quotes. Both are understood now, where before the request was refused and had to be made again.

Unchanged: every tool name, parameter and result shape. The levels and the call allowance.

2.1.0, 4 October 2026: your AI can send a draft that is already in your Drafts folder

• Ask your AI to send a draft that is already in your Drafts folder, one you wrote in Outlook or one it saved for you, and it sends it as it stands: the same recipients, words and attachments, still in its conversation if it is a reply. One copy goes into Sent and the draft leaves Drafts, as pressing Send would.
• Edit the draft as often as you like first. It goes as it is when it is sent, and if your edits gave it a new place in Drafts, your AI is shown your newest drafts with who each is to, so it can send the right one, or ask you when it cannot tell.
• A draft a colleague has asked to have approved is refused, so the approval cannot be skipped, and a draft already marked deleted is never sent a second time.
• Sends made this way show on your Failed sends card if a mail server refuses one, and in the Team weekly summary.

Unchanged: every existing tool name, parameter and result shape. The levels and the call allowance. Routines, which still never send.

2.0.2, 3 October 2026: searches skip a missing folder, near-miss names work, and a wrong folder never acts on another message

• Ask your assistant to search folders that include one your mailbox does not have, such as an "Archive" on Gmail, and it now searches the ones that exist. It says plainly which folder it skipped, that the count says nothing about it, and which folders you do have. Before, the whole search failed.
• Your assistant is no longer refused for using a near name for something: it can say query or text when searching, body or text when writing, uid or uids, ref or refs, and start and end or from and until on the calendar.
• A tool that acts on particular messages, such as deleting, moving, flagging or replying, now refuses a folder name it does not recognise and gives the right one. Before, it could ignore the name and act in your inbox, on a different message.
• A message whose date your mail server could not read no longer stops your inbox from being listed or searched. It is dated by when it arrived.
• When a draft your assistant is editing has changed, for example because you saved it in Outlook, the refusal lists your newest drafts so it can carry on with the right one. It never says the draft was sent.
• Your assistant is told not to write its own sign-off, because your mailbox adds your signature. Drafts and replies no longer end with a second sign-off above it.
• A routine's card counts only its own calls, so routines that run close together no longer add to each other's count. When a mail server refuses a command, your Activity tab now says which command and what the server said.

Unchanged: every tool name and parameter as clients see them. The levels and the call allowance.

2.0.0, 3 October 2026: routines, your own AI working your mailbox on a schedule

• Routines. On any connected mailbox's Routines tab you can choose a job for Claude or ChatGPT to do in your mailbox on a schedule, shape it in plain words, and add it to your AI as one of its own scheduled tasks: a morning brief, replies drafted for the people waiting on you, the emails nobody has answered, bills and invoices read from their attachments, or one you build yourself. All five, and how they work.
• Each saved routine's card says whether it ran, when, and how many calls it made, in the routine's own time zone. A run that has not come 2 hours after it was due in Claude, or 6 hours in ChatGPT, shows as "Did not run", with when it last ran, what to check and a button that adds the routine to your AI again. What each run found is in your AI's own list of scheduled tasks.
• list_identities takes an optional routine: the id of the routine making the call, which every Claude routine passes on its first call, so its card can say it ran. A ChatGPT routine cannot pass one, so its run is matched by its time. The call answers exactly as before.
• Why 2.0.0 and not 1.40.0: the major number marks the launch. Nothing was removed or renamed and no parameter changed its meaning.

Unchanged: every existing tool name, parameter and result shape. The levels and the call allowance; a routine's calls count against it like any other.

1.39.6, 3 October 2026: a revised draft keeps one signature, the right one

• Asking your assistant to change a draft, such as a reply it drafted for you, could leave the draft with two signatures: the one it had, and your new-message signature added again underneath the quoted email. update_draft now signs a draft only when it is not already signed, and signs a reply with your reply signature.
• A draft whose text already carries your signature, as one read back and edited does, is saved exactly as given. A draft rewritten from scratch gets the signature that fits it.

Unchanged: every tool name, parameter, description and result shape. The levels and the call allowance.

1.39.5, 3 October 2026: a newsletter's preview line is no longer reported as hidden text

• Most newsletters start with a hidden line, which your inbox shows as the preview under the subject. Every message read carries signals, named reasons it reads as written for your assistant rather than for you, and hidden text is one of them, so almost every newsletter came back as hidden text and as addressed to your assistant. A warning on every newsletter is one nobody reads on the message that earns it.
• That preview line is no longer reported when it is the first thing in the message, a body follows it, it is no longer than an inbox shows, and it asks for nothing: no request, no address and no link. Anything else hidden is reported exactly as before, including a preview line that asks for something, so the check on the threat model page still works as written.
• Our own emails no longer put an email address in their preview line, so none of them reads as hidden text either.

Unchanged: every tool name, parameter, description and result shape. The other signals, the levels and the call allowance.

1.38.2, 2 October 2026: inside ChatGPT, running out of free calls links to your account

• Inside ChatGPT, the message when a free mailbox has used its 5 calls, and the note on the call that uses the last one, now give a link to that mailbox's page in your Mailbox MCP account, where its plan and allowance are shown. They still name no price and make no offer, because OpenAI's plugin guidelines do not allow a plugin to promote an upgrade from inside ChatGPT. The same guidelines do allow a link to a page that describes your plan, and that is the link you get.
• Nothing changes anywhere else. Claude and every other client get the same message as before, with the price and the link to the mailbox's plan page.

Unchanged: every tool name, parameter, description and result shape. The levels and the call allowance.

1.38.0, 2 October 2026: 3 questions about the whole inbox, answered in one call each

• catch_up answers "what has come in?" for the last day, or since a time you name, up to a week back. The people who wrote come first, each conversation with a preview and whether you have already replied, checked against your Sent folder. Newsletters and automatic mail, such as receipts and account notices, are listed apart from them, and everything is counted, so a short answer never hides how much arrived.
• waiting_on lists what you sent that nobody has answered, oldest first, with how long each has waited and how many times you have already chased it. owed_replies lists the people who wrote to you last and are still waiting on you.
• Your assistant used to need several calls to answer any one of these: listing, opening messages to see who was a person and who was a newsletter, then searching Sent. Now each is 1 call, which is what makes a morning brief cheap enough to run every day.
• All 3 only read. They are on the most careful permission level, mark nothing as read and keep nothing: each answer is worked out from your mailbox at the moment you ask. Who counts as a person is judged from how a message was sent, never from what it says.
• Replies and forwards now quote the original's time the way its sender saw it. A message written at 06:10 in London no longer shows as 05:10 in the line above the quoted text, and where the sender's time zone cannot be told, the time says UTC rather than passing for theirs.

Unchanged: every existing tool name, parameter and result shape. The levels and the call allowance.

1.37.3, 1 October 2026: every tool describes what it does, without telling the assistant which to pick

• The same change as 1.37.2, carried through every other tool. Archiving, bounce checks, whole conversations, finding a contact, upload links, flags, approvals and the calendar now say what each one does, instead of telling the assistant when it must use it or that a change reaches nobody.
• A test now reads every description the server offers and fails if one starts ordering the assistant about or vouching for its own safety, so the wording cannot drift back.
• In ChatGPT's app directory the listing keeps the wording it was approved with until OpenAI approves the next version. Connected any other way, an assistant reads the new wording now.

Unchanged: every tool name, parameter and result shape, and what each tool does. The levels and the call allowance.

1.37.2, 1 October 2026: each tool's description says plainly what it does

• Before saving a reply draft, ChatGPT's safety check showed a warning, "Suspicious Instruction", because the description of the draft tools assured it that nothing would be sent and told it which tool to use. Both were true, but the wording read as an attempt to talk the check round. The three draft tools, the line about addresses from your own contacts, the delete, folder and upload tools, and the instructions every assistant receives now state what happens, plainly.
• The descriptions now give the measured cost of attaching a file written out as base64, roughly a million tokens a megabyte, where they said 450,000.

Unchanged: every tool name, parameter and result shape, and what each tool does. The levels and the call allowance.

1.37.1, 1 October 2026: inside ChatGPT, running out of free calls is explained without a price or a link

• Inside ChatGPT, the message when a free mailbox has used its 5 calls, and the note on the call that uses the last one, now say what happened, when the next call comes back, and that a larger allowance comes with a different plan. They no longer quote the price of Pro or link to the upgrade, because OpenAI's plugin guidelines do not allow a plugin to promote an upgrade from inside ChatGPT.
• Nothing changes anywhere else. Claude and every other client still get the price and the link to the mailbox's plan page, and the email to the mailbox's owner when its free calls run out is the same whichever assistant made them.

Unchanged: every tool name, parameter, description and result shape. The levels and the call allowance.

1.37.0, 30 September 2026: a saved password your mail server stops accepting is named, shown and emailed

• When your mail server stops accepting the password we saved for a mailbox, which usually means it was changed or a Gmail app password was removed, your assistant is now told exactly that, that trying again will not help, and where you fix it. Until now it got "Command failed" and nothing more.
• The control panel marks the mailbox "Password changed", and its Connection tab says why above the password form, with the Gmail app password steps on a Gmail mailbox. You are also emailed once, under a new switch in your alert settings. The first call that logs in again clears all of it by itself.
• A mail server that turns a login away for a reason that is not the password (busy, unwell, too many sessions) is not reported as a wrong password.

Unchanged: every tool name, parameter, description and result shape. A mailbox marked this way is still tried on every call, so a mail server's mistake costs a notice and nothing else. The levels and the call allowance.

1.36.0, 29 September 2026: a send or a draft names the files it carries, and Claude is told which setting lets it attach its own

• The result of send_email, reply_email, forward_email, draft_email, draft_reply, draft_forward and update_draft now lists every file that went on the message, by name and size, so your assistant can confirm what was attached rather than infer it.
• In Claude, a file Claude makes (a PDF, a spreadsheet, a chart) can be uploaded and attached by Claude itself, with nobody downloading anything, when Claude's code sandbox is allowed to reach mcp.mailbox-mcp.com. Where it is not, the upload link's result now tells Claude to give you the link for this file and to name the one setting that fixes it, once: network egress under Settings, Capabilities, or for a Team or Enterprise plan the Owner's Admin settings.

Unchanged: every tool name, parameter and description, apart from one clause on the upload link saying a proxy refusal is the same case as no network. Only Claude connections are told about Claude's setting. The levels and the call allowance.

1.35.0, 28 September 2026: ChatGPT attaches a file from its own conversation, with nothing downloaded first

• In ChatGPT, the tools that put a file on a message (send_email, reply_email, forward_email, draft_email, draft_reply, draft_forward and update_draft) take a new optional files input. An image ChatGPT has just generated, a document it made, or a file you dropped into the chat is handed to the server as a short-lived link, and the server fetches it and attaches it like any other file, under its own name. Tested in ChatGPT through the live service with a 2.8 MB generated image on a send, a reply, a forward and 4 drafts, each read back from the mailbox with the image attached.
• ChatGPT's link to a file lasts only a few minutes. If it has lapsed by the time the message is built, the message is refused with a note saying so, rather than going out without the file, and asking again is enough.
• A web link that answers with an error page is no longer attached as though it were the file. The message is refused and the error the web server gave is named.

Unchanged: every tool name, existing parameter, description and result shape. In Claude and every other client the tools are exactly as they were: the new input is offered to ChatGPT connections only, because only ChatGPT hands over files this way. The levels and the call allowance.

1.32.10, 26 September 2026: the call that uses a free mailbox's last call says so, with the upgrade link

• When a call uses the last of a free mailbox's 5 calls in 24 hours, its result now carries a short note for your assistant, after the result itself. Your assistant is asked to answer what you asked first, then tell you the free allowance is used, what Pro gives (1,000 calls in the same 24 hours, at once, with nothing to reconnect), the price, a link you can click, and when the next free call comes back in your own local time. Until now you only heard this if you asked for another call.
• The upgrade link in that note, in the message when a free mailbox is out of calls, and in the email that says so, now opens the upgrade straight away on the mailbox's plan page, including after you sign in.

Unchanged: every tool name, parameter, description and result shape, except that the one result which uses a free mailbox's last call carries one more text block. The levels and the call allowance.

1.32.8, 25 September 2026: when a free mailbox runs out, your assistant offers the way on first and gives the next free call in your own time

• When a free mailbox has used its 5 calls, the message your assistant receives now leads with the way on: Pro, which raises the mailbox to 1,000 calls in the same 24 hours, its price, and a link to the one button on that mailbox's plan page. Pro takes effect the moment payment completes, with nothing to reconnect, so the same request can be asked for again straight away. Your assistant is asked to give you the link as one you can click.
• When the next free call becomes available is now given as how long to wait, with the exact moment beside it, and your assistant is asked to tell you in your own local time rather than in UTC. The same goes when a Pro mailbox, or a person's own allowance on a shared mailbox, reaches its ceiling.

Unchanged: every tool name, parameter, description and result shape. The levels and the call allowance.

1.32.3, 25 September 2026: Outlook.com and Hotmail calendars work, common folder names are understood, and a refused search says why

• An Outlook.com, Hotmail or Live mailbox can now have its calendar. Microsoft does not give personal accounts the calendar permission a work account gets, so until now those calendars could not open, although the calendar tools were offered. A personal account is now asked for the calendar permission it can have, its own calendar, and gets reading, booking, moving, cancelling, answering invitations and the out-of-office reply. Checking when other people are free is not available on a personal account, and is no longer offered to one. A personal mailbox connected before today turns its calendar on by signing in with Microsoft again, and the control panel says so. Work and school accounts are asked for exactly what they were before.
• When your assistant asks for a folder by its everyday name, such as Sent, Archive, Junk, Spam, Trash or Drafts, it now reaches the folder your mailbox uses for that job, whatever that folder is called ("Sent Items", "[Gmail]/Sent Mail"). Renaming and deleting folders still take the exact name only.
• When a mail server refuses a search, the answer now says what the server said and what to do, such as trying again in a minute or narrowing the dates, and a search the server refuses for a moment is tried once more. A search Microsoft is throttling is answered straight away rather than tried again.

Unchanged: every tool name, parameter and result shape, and the levels and the call allowance. A personal Microsoft account no longer sees the two calendar tools that read other people's free time, which never worked for it.

1.32.1, 25 September 2026: a file just under the attachment limit is no longer refused before it is fetched

• A file already in the mailbox, or dropped on an upload link, is weighed before it is fetched, from the size the mail server reports. That size counts the line breaks inside the encoded file, and they were being counted as part of the file, so a set of attachments within about half a megabyte of the 20 MB limit could be refused although it fitted. The line breaks are now left out, and a file whose encoding the estimate cannot see into is weighed again once it arrives, so the limit holds either way.
• An alert the server sends about one of its own scheduled jobs now names the right places to look for that job.

Unchanged: every tool name, parameter, description and result shape. The levels and the call allowance.

1.32.0, 24 September 2026: attachments up to 20 MB a message, and a mail server's own lower ceiling refused before sending

• The attachments on one message may now come to 20 MB together, up from 10 MB. Measured live before release on all three routes a mailbox can send by: an IMAP and SMTP host, Microsoft 365 through Microsoft Graph, and Gmail over SMTP, each accepting a full-size message and filing its Sent copy with every file arriving byte for byte.
• Where a mail server advertises a lower size limit of its own, the message is refused before anything is sent, with a sentence naming that server's limit and what to do instead, rather than a bounce afterwards. A Sent copy or a draft too big for the mailbox to file is said plainly, and a message that went out but could not be filed is reported as sent, not as failed.

Unchanged: every tool name, parameter and result shape; two tool descriptions now state the new figure. The levels and the call allowance.

1.31.0, 24 September 2026: the operator's account list counts Pro mailboxes across a filter

• For the service's operator only: the control panel's account list now carries the number of accounts, mailboxes and Pro mailboxes across a whole filter rather than one page of it, and can download every matching account as a CSV file.

Unchanged: everything a customer or a connected AI client can see or call.

1.30.0, 24 September 2026: an occasional note about something new, with its own switch and one-click stop

• A third kind of note from us joins the getting-started emails and the allowance note: now and then, a short email when something new arrives in the service, such as a new kind of address book you can connect. It goes once per account, never once per mailbox, and never to an account whose address has not been confirmed. Like the others it carries a one-click stop that needs no sign-in, sent as the mail client's own unsubscribe header too, and its switch is under Settings in the control panel, Notes about something new. An account that has switched off any of our notes is not sent one.
• The first, on the day it shipped, was a letter from Pip about Google contacts. The privacy policy and the page for IT teams name the note, and Brevo delivers it as it does the others.

Unchanged: every tool, parameter and result shape; the consent flow; the levels and the limit. Nothing a connected client can observe moved.

1.29.5, 23 September 2026: /healthz says whether continuous backup is keeping up

• The server's own health endpoint, the one the public status page and the uptime monitor both read, gains a check for whether continuous backup of its database is keeping up: not-configured before continuous backup is switched on, then ok while segments keep arriving or stale if they stop. Only the last success is read, so one bounced connection to the backup store does not turn the public page red by itself; segments genuinely falling behind does.
• A stale backup check is now among the reasons the endpoint reports itself degraded, alongside the checks it already carried for the database itself, the nightly backup, its offsite copy and how long the audit record is kept.

Unchanged: every tool, parameter and result shape; the consent flow; the levels and the limit. A patch in the version scheme's sense: one more named state on an endpoint no AI client calls.

1.29.3, 22 September 2026: the rejected-sends list carries only what a mail server refused, and the recipient count reads the right key

• The control panel's Overview lists messages a mailbox's AI client tried to send that were refused, with the refusing side's own wording underneath each one. It had also been listing calls that were never sent to a mail server at all: an AI client's own tool arguments failing validation, and a send refused by the mailbox's own daily allowance, both already reported to the AI client at the time, in the conversation that produced them. The list now carries only a refusal that a mail server actually spoke, told apart by the SMTP status code inside its own wording, so it reads as a record of what genuinely bounced rather than a mix of unrelated failures under one heading.
• The sentence that used to sit under the list, telling a customer their AI client had been wrongly assured a message sent, is gone; the panel now says plainly that this is a record of what a mail server refused, in its own words, for after the conversation that hit it has scrolled away.
• Every row's recipient count, blank since the card shipped because the panel was reading a key the server never wrote, now reads the count the server actually returns.

Unchanged: every tool, parameter and result shape; the consent flow; the levels and the limit. A patch in the version scheme's sense: a control panel report reading the audit record it already had, not a change to what any AI client can call or receive.

1.29.0, 22 September 2026: Google contacts on a Gmail mailbox, by a Google sign-in of their own

• A mailbox that connects with a password, Gmail included, can connect its Google contacts: a Google sign-in of their own from the mailbox's Connection tab in the control panel ("If your contacts are in Google", then Connect Google contacts), offered where no CardDAV book is connected, since a mailbox has one address book at a time. The consent asks for the People API's https://www.googleapis.com/auth/contacts and openid email, to name the Google account that consented, and never for anything the calendar's consent asks for. It then gets the same 5 contact tools a Microsoft 365 mailbox's Outlook contacts get, always all of them: read_contact at Read only, create_contact, update_contact and import_contacts at Draft and file, delete_contact at Send and delete, and find_contact reads the book beside the mailbox's history.
• Open to every customer from 24 September 2026, the day Google verified the scope. The contacts permission is sensitive in Google's classification, so the release shipped with the offer switched off for everyone but the owner's own account while Google reviewed it, and nothing a Gmail or Google Calendar customer had changed in the meantime.
• Over the People API: a search is Google's own people:searchContacts after a warm-up sent when the book opens; the change probe is a sync token on people/me/connections; a create is one request and Google mints the id; a correction reads the person and sends only the families that changed, each whole, against the etag it just read; a delete reads the card, compares it with the revision held since the read that produced its id, and refuses on a difference, because the People API accepts no condition on a delete. Google contacts are one book, named Google Contacts: Google's labels are tags on a person rather than folders, so a label is not a book of its own to search or file into. Google's "Other contacts", the addresses Gmail collects by itself from people you have written to, are not reached, because they sit behind a second permission that is not asked for; find_contact finds those people in the mailbox's own history instead. A contact's photo is never requested on Google contacts, on a look-up or a correction, and a correction leaves the photo and the labels exactly as they were.
• The import. On Google contacts an imported card is skipped where the book already holds its first email address (Google mints the ids, as Microsoft does), a card with no email address is added every time, a group card is not imported, and the rest go to Google in batches rather than one at a time. On Google contacts the same named fields come across, each email address and phone number keeping its type; a birthday, a photo, a web address or the categories in the export do not.
• What is stored: the refresh token Google issued, sealed as the calendar's is, its scope string and which Google account consented, in three columns of their own beside the calendar's. No contact is stored. Disconnect this address book revokes the grant with Google, and a grant Google refuses marks the book for reconnecting and tells the owner once.
• Patched the same day, before anybody else could connect: 1.29.1 holds a Google contact's revision as the contact source's own etag, because the person's top-level etag changes with the fields asked for and every delete had been refused as changed; 1.29.2 makes both Google consents ask incrementally, so connecting Google contacts never disturbs a Google Calendar already connected on the same Google account, and the reverse; 1.29.4 sends the search warm-up when the book opens rather than just before the first search, so the first search on a cold cache no longer answers that nobody matched.
• Seen at contacts.google.com on 22 September 2026, on a real Google account: a card found, opened, corrected, deleted and created again from an AI client, each step confirmed there before the next.

Unchanged: every tool name, every parameter and every result shape on the mail, calendar, Team, CardDAV and Outlook contacts surfaces; the Google calendar consent, which never asks for the contacts scope; the levels and the limit. A minor bump because a route and three columns arrived.

1.28.0, 22 September 2026: Pip has an arc, so the welcome, the first call, Pro started and the Team invitation carry him and his pictures too

• 4 more of the account's automated emails carry Pip, the mascot the getting-started and allowance emails introduced, each with a picture of its own: the welcome sent the moment an address is confirmed, the note sent on a mailbox's first call, the one sent when a mailbox goes Pro, and the invitation Team Access sends to a new person. Together with the 8 getting-started emails and the allowance email, that is every warm moment in an account's life carrying the same character, and nothing else: the security notices, a decline, a refund, a renewal problem and anything that reaches the operator rather than the customer stay exactly as they were.
• The facts, the links, the buttons and the stop line each of these emails already carried are unchanged; what is new is the tone and the picture.

Unchanged: every fact, link, button and stop line the welcome, first-call, Pro-started and Team-invitation emails already carried; the consent flow; the levels and the limit. A minor bump because 4 more messages gained an image apiece.

1.27.1, 22 September 2026: the allowance email is Pip with his cape on the hook, and Pro is the cape

• The email a mailbox's owner gets when its free daily calls run out now carries Pip too, with a picture of him beside the mailbox, and frames Pro as what lets him keep going rather than as something being sold: the tools are the same on both plans, so nothing in the new wording claims Pro unlocks anything. The facts, the wait until the next call frees up, the price, the once-a-day promise and the stop link are all unchanged.

Unchanged: every fact, the wait time, the price, the once-a-day promise and the stop link the allowance email already carried; the consent flow; the levels and the limit. A patch in the version scheme's sense: one email gained a tone and a picture.

1.27.0, 21 September 2026: the getting-started emails carry a running joke about Pip, and each carries its own picture of him

• The 8 getting-started emails (the no-mailbox track and the no-call track, 4 messages each) now carry a running joke about Pip, the Personal Inbox Pilot assigned to every account the moment it signs up, and what he gets up to while waiting to be given something to organise. The joke escalates differently across each track's 4 steps, and each message carries its own picture of him rather than one image reused across all 8.
• The facts, the links, the buttons and the one-click stop every one of these emails already carried are unchanged; what is new is the tone and the pictures.

Unchanged: every fact, link, button and stop line the 8 getting-started emails already carried; the consent flow; the levels and the limit. A minor bump because every message gained an image.

1.26.2, 21 September 2026: Outlook.com's IMAP switch as a failure code

• A personal Outlook.com or Hotmail mailbox where the Microsoft sign-in succeeds and the mailbox itself then refuses IMAP, because a personal account keeps that switch off by default, now gets a named remedy rather than a dead end: the control panel's credentials screen says Outlook.com is not letting apps open the mailbox yet, that the switch is off, and the exact path to turn it on (Settings, Mail, Forwarding and IMAP), with a section of the Microsoft 365 guide showing where. Until this release the same failure answered with a generic instruction to check the failed step below, and no step was shown.
• The getting-started email for a personal Microsoft address links straight to that section under its own current name.

Unchanged: every tool, parameter and result shape; the consent flow; the levels and the limit. A patch in the version scheme's sense: what a Microsoft account with the switch already on can do is untouched, and only what a customer with the switch off is told about it moved.

1.26.1, 21 September 2026: the walkthrough video in the emails

• The same 6-minute walkthrough video the site shows (a sign-up, an IMAP mailbox added, the connector pasted into Claude, and 2 example prompts answered) is now offered inside the getting-started emails, at the 2 points people get stuck: the track for an account with no mailbox yet, at 1 hour, 24 hours and 5 days, and the track for a mailbox nobody has called through yet, at 1 hour (only while nothing has connected), 24 hours (beside the guides) and 5 days.
• It is not offered in the safety note, the 3-prompts note, the allowance email or the first-call email: each of those is either past the point the video helps, or already about to end in success on its own.

Unchanged: every fact, link, button and stop line the getting-started emails already carried; the consent flow; the levels and the limit. A patch in the version scheme's sense: one link joined 6 existing messages.

1.26.0, 20 September 2026: your first call gets one note back: it worked, and the same connector goes into every other AI

• The moment an account's owner makes their first call through a mailbox, one email from Mark: it worked, which mailbox and which tool, three things to ask, and the thing most people do not realise, which is that the connector is not tied to the AI that made the call. The email is worded from that AI: a first call from Claude gets a section on putting the same connector into ChatGPT, a first call from ChatGPT gets one on Claude, a first call from Claude Code gets both, and a first call from a client we cannot name gets both and is called "your AI" rather than by a name the client chose for itself. A last section lists the editors and the guide for every client. Once per account for ever, on the owner's own call and never on a shared person's, and it is the last note of the getting-started series, so the same switch and one-click stop govern it. Everybody who was already calling before this release got the note once, worded for someone already past their first call, on the day it shipped.

Unchanged: every tool, parameter and result shape; the consent flow; the levels and the limit. Nothing a connected client can observe moved.

1.25.0, 19 September 2026: when a free mailbox runs out, you are emailed when the first call is back

• When a mailbox on the free plan uses the last of its 5 calls (the fifth admitted, or a sixth refused), its owner gets one email from Mark: which mailbox, when the first call is back in hours and minutes with the GMT time in brackets, that the rest follow one by one as each reaches 24 hours old, and what Pro costs with the plan page's button. It says the tools are the same on both plans, because they are. Never more than once a day per mailbox, never on Pro or on a shared person's own cap, and every one carries a one-click stop; the switch is under Settings, What we email you about.
• A URL in the body of any email we send is now a link in the HTML part, where before it was plain text and whether it was clickable depended on the reader's mail client. Only our own two hosts and the few third-party pages the guides point at (Google's app-password page today) are linked; any other address in an email stays text, so nothing that arrives from outside can become a link in a notice we signed.

Unchanged: every tool, parameter and result shape; the consent flow; the levels and the limit itself: a refused call still says when the next one frees up, and nothing about the meter changed.

1.24.0, 19 September 2026: the getting-started emails: a few notes from Mark in an account's first days

• An account that has not finished setting up hears from Mark a few times: an account with no mailbox gets 4 short notes at 1 hour, 24 hours, 48 hours and 5 days after sign-up, each giving a different reason to add one and the route that fits the mailbox it most likely has; an account whose mailbox no AI has called through gets 4 more from the mailbox's first day, moving from how to point your AI at it, to 3 things to ask it (a diary and an address book question only where the mailbox has them), to what usually gets in the way. Every one is different, greets you by first name where we have one, and stops by itself the moment you add a mailbox or make a first call.
• Every one of those emails carries a one-click stop that needs no sign-in, and the same switch (Getting-started tips while you set up) is under Settings, What we email you about. They are sent as Mark at Mailbox MCP with the support inbox as the reply address, and go through Brevo's sending service, which the privacy policy and the page for IT teams now say.

Unchanged: every tool, parameter and result shape; the consent flow; the levels and the limit. Nobody who already has a mailbox and has used it hears anything new.

1.23.0, 18 September 2026: one address is one mailbox on an account

• An account holds one mailbox per address. Signing in with Microsoft a second time for an address the account already has re-authorises that mailbox (same id, same plan, same connections, a fresh sign-in) and the panel lands you on it, one click from its plan page; a password add of an address already held is refused naming the mailbox it already is, and the panel takes you to that mailbox's Connection tab, where a new password goes. Until 1.23.0 a second sign-in stored a second copy, which the first paying customer found by pressing the button twice 30 seconds apart.

Unchanged: every tool, parameter and result shape; the consent flow; the levels and the limit. A mailbox already stored twice from before this release stays as it is: nothing is merged or removed without you.

1.22.0, 18 September 2026: accounts that hold nothing are removed, after a warning

• An account whose address nobody confirmed (no confirmation link came back, and no Google or Microsoft sign-in vouched for it) is deleted 30 days after it was created, with no email, because nobody has shown the address is theirs to write to. A confirmed account with no mailbox is deleted after 90 days without a sign-in to the control panel, and is emailed 14 days before with the date; signing in or adding a mailbox keeps it. An account with a mailbox is never deleted for being idle, however long since anyone opened the panel, because an AI client uses it without one. The same three numbers are in the privacy policy and the terms.
• Every removal is preceded by a row in the administrator's log naming the rule and the dates, and made through the same function an account's own Erase uses.

Unchanged: every tool, parameter and result shape; every account that holds a mailbox; every paid period. Nothing a connected client can observe moved.

1.21.0, 18 September 2026: a Google or Microsoft sign-up is a confirmed account

• An account created by signing in with Google or Microsoft is confirmed, by that provider, and is treated as one everywhere: it is never listed as unconfirmed, it is never asked to confirm by email, and the two things that happen when an account becomes real, the welcome email and the operator's notice, happen on that sign-in as they do on an email confirmation. Until 1.21.0 a Microsoft sign-up read as unconfirmed on the administrator's screens (Microsoft does not assert that an address is verified) and neither email was sent for either provider.

Unchanged: every tool, parameter and result shape; the sign-in flow itself; what an email sign-up is asked to do. The rule that decides whether a provider sign-in may attach itself to an existing account is unchanged on purpose.

1.20.0, 18 September 2026: the operator's notification switches move into the control panel

• The three operator notices of 1.18.0 are switched on and off, and given their address, on an administrator-only page in the control panel rather than in the server's configuration file. The setting is read at the moment a notice is sent, so a change is live on the next event with no restart.

Unchanged: every tool, parameter and result shape; every customer-facing screen and email. Administrators only.

1.19.0, 18 September 2026: a sign-up that began from Connect is told the three steps, and a welcome follows confirmation

• Somebody who presses Connect in Claude or another AI client, has no account, and creates one is now told the three steps in the confirmation email (confirm, add the mailbox, approve the connection) and is sent back to finish the connection after the mailbox is added, rather than left on the panel with no way back to the client. Every confirmed account then receives a welcome: what to do first, the guides for each kind of mailbox and each AI client, and where support is.

Unchanged: every tool, parameter and result shape; the plain sign-up, which keeps its plain confirmation email.

1.18.0, 18 September 2026: the operator is told of a new account, a new mailbox and a payment

• The service emails its operator when an account is created, when a mailbox is added and when a Pro or Team invoice is paid, each switchable and to an address of the operator's choosing. Nothing in any of the three goes to a customer, and none carries a credential or a message.

Unchanged: every tool, parameter and result shape; every customer-facing screen and email.

1.17.1, 17 September 2026: a cleared Outlook address is an empty slot, and an empty folder is not searched

• Clearing a postal address on an Outlook contact works. Under 1.17.0 "drop Bob's home address" on Outlook contacts sent Microsoft an empty value it refuses, so the request failed and the address stayed; 1.17.1 sends the empty shape Microsoft documents for a cleared slot, and the server's own stand-in for Microsoft now refuses the old form as the service does, so the mistake cannot come back unseen. Seen in Outlook's People on 17 September 2026: an address cleared from ChatGPT left the contact with none, read back before the contact was deleted.
• An empty folder is not searched: find_contact's history half skips a folder that holds no messages rather than asking the server for its most recent 3,000 messages, which on an empty folder is a question with no answer, and the folder is still reported as searched.
• Two sentences read more exactly: the Microsoft clause on create_contact and update_contact says an untyped postal address is filed as other, and the note on a result whose history was cut says "a person last in touch with before that", since the inbox is bounded as well as the sent folder.

Unchanged: every tool name, every parameter and every result shape; the consent flow, the levels and the limit. No migration, no new dependency, no key moved on any answer. A patch in the version scheme's sense.

1.17.0, 17 September 2026: the postal address is the tenth field on a card, and find_contact reads a bounded history

• A contact card carries postal addresses, on both routes: each typed home, work or other, with street (up to 2 lines), town, county or region, postcode and country. A card opened with read_contact carries them, and so does a person find_contact found in the book, so "what is Bob's address" is answered by the same call as his number; the whole card is now every name, every email address with its type, every phone number with its type, the postal addresses with their type (home, work or other), each with street, town, county or region, postcode and country, the employer, the job title and the note.
• create_contact and update_contact take postalAddresses (at most 5, at least one of the 5 parts on each): on an update the array replaces the whole list and an empty value clears it, as email addresses and phone numbers do. On Outlook contacts there is one address of each type, an untyped one is filed as other, and a card naming 2 of one type is refused before Microsoft is asked. import_contacts carries the addresses in an export on both routes: a CardDAV import writes the whole card as it always did, and on Outlook contacts the address now crosses where 1.16.0 dropped it.
• A postal address is a field you read and write and never a search term: find_contact still matches names, nicknames, email addresses and employers, and "who do we know in Glasgow" is not a question it answers. An address is held in memory for the same about 10 minutes as every other field and never written down, and the record of a call holds how many addresses it carried and never a street, a town or a postcode.
• The mailbox half of find_contact reads each folder's most recent 3,000 messages rather than every message it holds: the search over a folder of 27,000 messages had cost the mail server 27,000 headers and the owner 8 to 20 seconds a call. The result says so in one sentence only when a folder held more, so a mailbox that fits gets exactly the answer it always did; the cost, paid by the history half alone, is that a person last in touch with before the window is not in it, and the book still has them if they are in it.
• Seen in Thunderbird on 17 September 2026 on the CardDAV route: a card created with a home and a work address, both with postcodes, shown under Thunderbird's own labels with every part on its own line. Seen in Outlook's People on 17 September 2026, on 1.17.1: an address created, its postcode corrected, the address removed and the contact deleted, from ChatGPT, each step read back.

Unchanged: every tool name and every parameter that existed; a card result gains <code>postalAddresses</code> and a <code>find_contact</code> result <code>historyWindow</code> and <code>historyTruncated</code>, keys that were absent rather than changed. No migration: nothing about an address is stored. The consent flow, the levels and the limit.

1.16.0, 17 September 2026: a Microsoft 365 mailbox brings its Outlook contacts with the sign-in

• A Microsoft 365 mailbox whose consent covers the contacts permission gets the same 5 contact tools a writable CardDAV book gets, over Microsoft Graph, its Outlook contacts being the book: read_contact at Read only, create_contact, update_contact and import_contacts at Draft and file, delete_contact at Send and delete. Nothing to connect, no address to give, nothing stored beyond the grant the mailbox already had; find_contact reads the Outlook contacts beside the mailbox's own history exactly as it reads a CardDAV book. The consent screen asks for Contacts.ReadWrite from this release, its sixth permission: delegated, not requiring admin consent in Microsoft's classification, and ReadWrite because cards are imported in as well as read out.
• The books are the default Contacts folder, the user's own top-level contact folders and their child folders one level deep, at most 30 in all, every one writable; a folder nested deeper, or shared or delegated by another user, is not among them. Graph has no per-folder rights on the owner's own contacts, which is why every one is writable. A contact's reference is the book's id and the contact's, and each folder's delta link is the change probe, held in memory as a CardDAV book's ctag is.
• The Microsoft rules of the import and the writes. On Outlook contacts an imported card is skipped where the folder already holds its first email address (Microsoft mints the ids, so there is no card id to land on twice), a card with no email address is added every time, and a group card is not imported. On a Microsoft mailbox the fields this server names come across (name, emails, phones, postal addresses, company, job title, note); a birthday, a photo, a web address or the categories in the export do not, and a card with two postal addresses of one type keeps the first of each, since Outlook holds one home, one work and one other address. A folder past the index bound refuses the import with a fixed sentence. On Outlook contacts a new card is one request to Microsoft, which mints the card's id, so there is nothing to be already taken and nothing to write over. A correction and a delete fetch the card, then PATCH only the fields named or DELETE, each with If-Match on the ETag just read, a 412 answered as "the card changed since it was read" and never retried. An email address on an Outlook contact carries no type (home, work), and a phone number typed as other is filed as a work number, because those are the fields Microsoft offers. A contact's photo is never requested on Outlook contacts, on a look-up or a correction.
• A Microsoft mailbox whose grant was recorded before this release lacks the scope: it keeps its mail and calendar tools, gets no contact tools, and its mailbox body's contacts.why and the control panel's address book card say to reconnect it once with Microsoft; nothing about its connection is wrong until it does, and no email is sent about it. A grant Microsoft refuses at the book's open marks the book column only (graph_contacts_refused, the remedy a reconnect), never the mailbox's, and tells nobody. The mailbox body's contacts object carries canReauthorise on every route and provider reads microsoft where the grant covers the scope; PUT and DELETE of a CardDAV address on a Microsoft mailbox still answer 409 contacts_not_editable, the detail now saying either that the book came with the sign-in and has no address to give or remove, or that the grant wants the reconnect.
• Carried from 1.15.x: a Microsoft or Google service error reaching an audit row or a tool answer is a fixed sentence with the provider's code in brackets, and the provider's own words sit on a separate detail the control panel shows where a person reads it, so a Graph validation message quoting an attendee's or a contact's address never reaches the record; the calendar's six "there is no event in" sentences and the two that quoted a calendar's display name are fixed sentences too; and the stored-authorisation-invalid refusal no longer carries the mailbox address or the token endpoint's description in its message.
• Seen in Outlook's People on 17 September 2026: a card created from ChatGPT, corrected and deleted, each step confirmed there.

Unchanged: every tool name, every parameter and every result shape on the mail, calendar, Team and CardDAV surfaces; the consent flow's five earlier permissions; the levels and the limit. No migration: the Microsoft route stores nothing new. A minor bump because the consent screen gained a line and the mailbox body a key.

1.15.2, 16 September 2026: a repeated import skips what the book already holds without asking the server

• Running the same export again costs the book one change check (and a sync where it moved), not one write per card: import_contacts now answers "already there" from the book's own index for a card it knows, and pays the write only where the index does not know the address. Under 1.15.1 every re-run walked the file from the first card and paid one refused write per card already in the book, so on a large export a second run could spend its 40 seconds re-refusing the cards the first run wrote and stop at the same place, and "run it again and it continues where it stopped" was false above a few hundred cards. A 500-card import that stopped at the budget now finishes on the next call.
• A card on the server that is not a vCard is named as such, with the book in the fenced part of the answer, where 1.15.1 had reported it as the book not answering and sent the model back to retry a read that could never succeed. Reads, corrections and deletions all say it.
• The mailbox failing under the import's fetch of the file reads as one sentence, "the file could not be read from the mailbox; try again", where 1.15.1 let the mail server's own words into the answer and the activity log.
• A UTF-8 export that begins with a byte order mark keeps its first card whatever character set the mail part declared: the mark is read before the label is believed. Under 1.15.1 such a file under an 8-bit label decoded its first line as garbage and lost the first card.

Unchanged: every tool name, every parameter and every result shape, the consent flow, the levels and the limit. No migration, no new dependency, no key moved on any answer. A patch in the version scheme's sense.

1.15.1, 16 September 2026: a transport error never names a card, an import has a time budget and a backoff, and an export's character set is honoured

• A card whose read or write timed out, or whose server dropped the connection, is answered "the address book did not answer; try again" in the tool result and in the activity log, never with the card's filename. Under 1.15.0 the transport's own sentence named the address it was fetching, which on a CardDAV server is the card's path and, on some hosts, the person's name; it could reach the activity log through read_contact, update_contact and delete_contact, and the calendar's read_event and update_event shared the channel. The fix sits at the one seam every DAV call passes through, so the calendar tools get the same sentence. The transport's reason goes to the server's own journal under the tool's name.
• import_contacts writes 3 cards at a time and runs under a clock: after 40 seconds it stops with its counts and says "run it again and it continues where it stopped", so a large export ends with counts rather than a client-side timeout that throws them away; a client that gives up on the request stops the writes the same way. Under 1.15.0 a 500-card export was written one card at a time with no clock, which at the 200 ms a card one host was measured at is longer than the 60 seconds the MCP SDK's client waits for a request by default.
• A 429 or a 503 from the address book stops the import at once with "the server asked us to slow down; run the import again in a minute and it continues where it stopped"; the card it answered is not counted and the next run tries it again. Under 1.15.0 either counted as a card's failure, and 5 of them ended the run with a sentence that blamed the cards.
• A contacts file is decoded in the character set its attachment declares (windows-1252, ISO-8859-1 and the rest), so an export with accents lands with them; a file that declares none and is not valid UTF-8 is refused before the book is asked, with "export it again as UTF-8", because a write into a person's book must not guess. Under 1.15.0 every file was read as UTF-8 and a windows-1252 export was written with replacement characters in the names.
• The tool's own description now says a card already earlier in the same export is skipped as a duplicate, that a fileRef from check_upload (a file dropped on an upload link) is a way in beside one from read_email, and that the run stops itself after 40 seconds or on a slow-down and continues on the next call. A card the server accepted but this process could not read back is that card's own failure and is found existing on the next run, where under 1.15.0 it ended the run with the rest of the file unwritten.
• Two refusals that carried a book's own display name or the account's book ids ("this address book is read-only", "addressBook does not name exactly one of this account's address books") now carry them inside the fenced part of the answer, so the assistant reads the name exactly as before and the activity log keeps only the fixed opening. And a request the server itself refuses for its shape (a name over 300 characters, an address that is not one, a note over 4,000) writes a row naming the field and the rule and none of the value.

Unchanged: every tool name, every parameter and every result shape, the consent flow, the levels and the limit. No migration and no new dependency (the character sets come from the runtime's own decoder). Every new stop is a sentence under the <code>stopped</code> key an import's answer already had. A patch in the version scheme's sense.

1.15.0, 16 September 2026: a card can be written, and a webmail export can be imported

• On a mailbox with a CardDAV address book whose sign-in may write to it, 4 tools join read_contact: create_contact (a full name, and optionally given and family names, a nickname, email addresses and phone numbers each with a type, the employer, a job title and a note), update_contact (only the fields named change; null clears one; the lists of addresses and phones are replaced whole; a card cannot lose its name), delete_contact, and import_contacts. The create, the update and the import sit at Draft and file; the delete at Send and delete, beside delete_email and delete_event, and it carries the destructive annotation. Whether a book can be written is read from its privilege set when it connects, so a read-only book keeps the one tool and the count a connection is handed is derived, one or 5, never typed; the consent screen's Draft and file and Send and delete lists each gain one line naming what the level may do to an address book the customer has connected.
• Every write is preconditioned on the wire and never retried. A create is a PUT to a fresh address with If-None-Match: *; an update and a delete always read the card again first, take its ETag and write with If-Match, so a card another client changed since is answered CARD_CHANGED and the model is told to read it again rather than the card being written over; a card gone from the book is CARD_GONE. An update is applied to the card as the book holds it, so the photo, the birthday and every line the tool does not name survive; a card is written as vCard 3.0 unless the book names only 4.0. With one writable book a write goes there; with several, addressBook names one (by its id or its display name) and a write naming none is refused with the writable ones listed. A create is the one write that is not idempotent: a second call files a second card, so its description says to call it once and, after a timeout, to check with find_contact before trying again. An update with nothing to change is refused before the book is asked, since writing a card back unchanged would still show it as modified in every other client.
• import_contacts takes a vCard export that is already in the mailbox, by the fileRef a read_email result carried for the attachment, and nothing else: no URL, no pasted content, no path. The engine weighs the file from the size signed into the ref before a byte is fetched (at most 2 MB), checks the signed name and type (text/vcard, text/x-vcard, text/directory, or a .vcf or .vcard name), then parses the bytes into at most 500 cards and writes each once with If-None-Match: * under the export's own UID or, where the export wrote none, a digest of the card's own text, so a repeated import finds every card already there. The answer carries counts (created, alreadyThere, failed, skipped) and the first 25 names created, never the cards; five server refusals in a row stop the run with the counts so far. A vCard 2.1 export, which Outlook desktop still writes, is answered with a sentence naming the fix. The file's bytes live in the process for the one call.
• Measured on the way and kept in the tests: one common webmail's export writes no UID and no PRODID, puts N before FN and lower-cases its type values, which is why a card without a UID is filed under a fingerprint of its own text rather than a random id; a fixture written from the RFC would have carried a UID on every card and tested the import's idempotence against a shape that export never produces.
• The audit record: the argument names of every contact tool are on the store's counted or redacted lists by construction (emails, phones and cards are kept as counts, everything else as [redacted]), a number under a counted name is kept only while it is a plausible count, and an import's card count reaches the row as a signal on the result (cards-<n>, created-<n>); an end-to-end test drives each write through the real auditor and asserts that no fragment of the card reaches the row. The refusals a write can produce are the engine's fixed sentences, never a string built from an argument.
• Accepted in a real contacts client before this entry was written: Thunderbird over CardDAV on a disposable book, the four writes and the import run twice over a live MCP session against the deployed server. A created card arrived with its name split as given and family, its email typed WORK and its phone MOBILE, and nothing extra; an update changed the title and added a second email with the photo and the birthday intact; a delete removed the card and left the rest; the import created 2 cards on its first run and reported both already there on its second, on the same addresses. The screenshots are the acceptance record and live in the server repository.

Unchanged: every mail, calendar and Team tool, every parameter and every result shape, the consent flow, the levels and the limit. No migration, no new dependency, and no change to any response shape: the connect route's <code>tools</code> list on a writable book now names five tools where it named one, which is the same shape. A book connected under 1.14.x that its sign-in may only read behaves exactly as it did.

1.14.2, 16 September 2026: the refused-credential remedy names the hosts that want an app password, and no others

• The remedy a refused CardDAV or CalDAV credential is answered with (contacts_credential_refused, calendar_credential_refused) now names Fastmail and iCloud as the hosts that refuse an account password and want an app password made in the account's security settings, and says that on a host which switches the calendar and the address book on per mailbox tier the mailbox password is the right one and a refusal means the tier is not on yet. It had listed such a host among the app-password ones, sending its customers to a security setting that does not exist, and the calendar's remedy had named Google, which is not reachable over CalDAV at all. The control panel shows the sentence beside the address field; nothing is stored either way.

Unchanged: every tool, every parameter and every result shape, the consent flow, the levels and the limit. What moved is the wording of one remedy on each of 2 routes.

1.14.1, 16 September 2026: a server's error body stays out of the audit record, and an address carrying a password is refused

• When an address book or calendar server refuses or fails a request (a 403 on one card, a locked collection, a rate limit, a 5xx), the sentence a connected client is answered with, and the sentence written to the audit record, is now fixed text built from the status and the request's own nouns, and never carries the server's error body. The review that produced this release reproduced the channel with the real tool behind the real auditor: a 403 on one card from a sabre-family server names the card's path, .../ada-lovelace.vcf, a file name a provider builds from the person's name as often as not, and it had landed in the audit record's error column beside an argument column that said [redacted]. The calendar tools had carried the same channel since the CalDAV client was built on 2 September 2026, and it is closed by the same change; the per-book addressBooks.skipped sentence in a find_contact result carries the fixed sentence too. Where a server's own words still go, decided consumer by consumer: the providerMessage the control panel shows beside the address field when a book or calendar is tested, produced before any card or event is read and stored nowhere; and the server's own log, with the reconnect reason recorded on the mailbox, when a stored book or calendar fails to open, where the server's sentence is about the address the customer gave and nothing else.
• A CardDAV or CalDAV address that carries a username or password inside the URL (https://user:secret@host/) is refused before any request is sent, as contacts_url_invalid or calendar_url_invalid, with the remedy "The address must not carry a username or password; give those in the fields below." No request had ever been sent to such an address, but the refusal was misreported (contacts_unreachable, "Nothing at that address answered", about a server that was never asked; calendar_not_found on the calendar side) and the address, secret included, was written to the server's own log on the way out. Every log line and the url echoed on a test result now carry the address with the credential stripped.

Unchanged: every tool name, every parameter and every result shape, the consent flow, the levels and the limit. No migration, no new dependency, and no change to any response shape: the 2 refusals above answer with keys the control panel API already records for a refused address. A patch in the version scheme's sense: what moved is the wording of a refusal, and where a server's own words are allowed to travel.

1.14.0, 16 September 2026: an address book, connected and read

• A mailbox that connects with a password (Gmail by app password, or any IMAP host) can have a CardDAV address book connected to it: PUT /mailboxes/:id/contacts takes the server's address and, where the book wants one, a username and password of its own, otherwise the mailbox's password is used. The book is opened before anything is stored, with the same 6 refusals the calendar has in its own words (contacts_url_invalid, contacts_blocked, contacts_credential_refused, contacts_forbidden, contacts_not_found, contacts_unreachable), and a refusal stores nothing. POST /mailboxes/:id/contacts/test tries a stored book again and DELETE removes it. A mailbox that signs in with Microsoft answers 409 contacts_not_editable: its contacts come with that sign-in in a later release. Every mailbox now carries a contacts object saying whether a book is connected, which provider, and why not where one cannot be.
• Where a book is connected, one tool joins every connection to that mailbox at the Read only level and above, and there is no switch for it: read_contact opens one card by the reference a search handed back, with every name, every address and phone number each with its type, the employer, the job title, the note and which book it is in, and says in the answer that photos are not read. A reference that names no card, or a card deleted from another device, is answered with a sentence rather than a broken connector. A mailbox with no book registers nothing from this surface and is told nothing about it.
• find_contact reads the book beside the mailbox's own history on every call, from the same tool name a client already knows. Every result carries source (the address book, the mailbox, or both) and a person from the book is marked book, a band above strong, with every address, the phone numbers, the employer and the job title on the result, so "what is Bob's number" is one call. A book that will not open is named in the answer under addressBooks.skipped and the mailbox's own evidence is still returned. (The source key and the reworded note for 2 confirmed matches are 1.13.0's, below, and were on every mailbox before a book could be connected.)
• Nothing about a contact is stored, and that is tested rather than asserted: a card is fetched from the customer's own server to answer the call, held in memory for about 10 minutes after it was last touched, and forgotten; a test reads every database migration and fails on any column named for contact data that is not on its short list (the book's address, its username and its sealed password, and an older consent flag); the audit record of a contact call holds the tool name, the outcome and [redacted] for every argument, and an end-to-end test drives read_contact with a person's name where the reference belongs and asserts the name reaches no row. On the server itself, swap is absent and the 3 services are set to write no core file, so memory cannot reach a disk either way.
• A book whose credential is refused after it was stored is marked on the mailbox (needs_reconnect, carddav_auth_failed with an app-password remedy), the owner is emailed once, and the mail tools are unaffected; a book that opens again clears the mark.
• POST /auth/totp/enrol answers qrSvg beside the secret and the otpauth URI: the URI as one inline SVG a control panel can show for an authenticator app to scan, drawn by the API because it is the side that holds the secret. Neither the secret nor the URI appears in the picture as text.

Unchanged: every mail, calendar and Team tool, every parameter and every result shape, the consent flow, the levels and the limit; the 2 additions to existing shapes are the contacts object on every mailbox in the control panel API and qrSvg on enrolment, both additive. A mailbox with no address book connected, which is every mailbox that existed before this release, behaves exactly as it did under 1.13.1.

1.13.1, 16 September 2026: the redirect carries its provenance, and a card lives in its book

• Engine fixes to the address book layer of 1.13.0, which no customer could yet connect. A 401 that arrives after a redirect to another host (StackMail's .well-known/carddav sends the client to contacts.stackmail.com, and a browser-grade fetch drops the credential across hosts) is read as "not here" rather than as a refused credential, so discovery walks on to the customer's own path; the production fetch had reported no redirect at all, so on the deployed server every StackMail address book would have stopped at its first candidate. A card reference is checked against the account's own books before any request is sent, so a reference naming another host, another port or another collection cannot send the customer's credential anywhere, and the calendar's event ids gained the same check on every path that takes one.
• A card is forgotten about 10 minutes after it was last touched even while the mail tools keep the mailbox busy, by a sweeper the adapter owns rather than a check at the top of each contacts call, and a closed adapter empties at once. A card that cannot be parsed is refused with a sentence naming the book and never the card's file name. A truncated change report from a server is noticed and completed from the book's index rather than trusted as whole. The capped-search note distinguishes a scan that stopped at its bound from a server that returned more matches than were asked for.
• The review that produced this release also found that 1.13.0 had changed 2 things a client could see, which its own record had called unchanged: every find_contact result carries source, and the note for 2 confirmed matches was reworded. Both are recorded under 1.13.0 below, and both stand.

Unchanged: every registered tool, every parameter and every result shape. No migration, no new dependency. The one thing a client on a mailbox with a calendar can observe is the refusal above: an event id naming a collection outside the account's own calendars is now answered with a sentence before any request is sent, where it had reached the server; every well-formed id behaves as it did.

1.13.0, 16 September 2026: the CardDAV client and the memory-only cache, measured

• Two things a connected client can see, on every mailbox, found by the review that produced 1.13.1 after this release's own record had called the payload unchanged: every find_contact result carries source: "mailbox" (an additive key; no result carried source before), and the note for 2 confirmed matches reads "each is confirmed (in the address book, or written to before): do not pick one; show the user the choices and ask which they mean" where it had read that the user had written to all of them.
• Nothing else a customer or a connected client could observe moved: nothing new was registered, no migration ran and no dependency was added. The release is the engine's address book layer built behind a seam nothing yet passed: a CardDAV client beside the CalDAV one (discovery, the books, a filtered search, a batch fetch, the change counter and the change report, get, put and delete, never looking inside a card), a vCard reader that keeps 9 fields and removes the photograph on parse, a read-only adapter over both, and the cache the whole design rests on: memory only, a card kept about 10 minutes after it was last touched, at most 2,000 cards or 1 MiB of parsed text a mailbox, the search memoised per book until the book's change counter moves.
• Measured before it was designed further, against 2 CardDAV servers stood up for the purpose (Radicale 3.8.0 and Baikal 0.12.1 on sabre/dav) and against StackMail. All 3 honour a filtered search, so a search for "bob" returns the 3 people called Bob and nothing else leaves the server; Radicale ignores a result limit and returns every property including the photograph, so the reader strips it; sabre honours both. All 3 offer the change report, so a book where one person changed re-fetches that card and not the book. A search on a warm cache with nothing changed is 1 round trip a book (45 ms on Baikal's one book, 33 ms across Radicale's 2, from the machine the fixtures ran on); cold, 2 to 5 round trips (128 ms and 68 ms); opening a card already in memory is 1 round trip. On a server that will not search, a bounded scan reads at most 1,000 cards, 100 a request, and the answer says it capped.
• What it prepares for: find_contact can be handed a book and then reads it beside the mailbox's history, ranking a card first; no mailbox was yet handed one. 1.14.0, above, is the rest: the address book connected, and the card opened.

Unchanged: every tool name, every parameter and every result shape apart from the 2 lines above, and the consent flow, as they were under 1.12.2. The version moved because the engine did, and a client comparing versions deserves to know it moved for a layer it could not yet reach.

1.12.2, 15 September 2026: the complimentary-access warning, one preposition

• The sentence 1.12.1 changed is reworded: once the warning names a day, "at" was the wrong preposition, so the clause now reads ends by itself on 22 September 2026 rather than ends on its own at 22 September 2026, which is how the admin surface's own complimentary-access card already put it. The rest of the sentence is as it was.

Unchanged: everything a customer or a connected client can observe. Every tool, every parameter, every result shape and the consent flow are as they were under 1.12.1; the sentence is returned to an administrator of this service, on the staff-only admin surface, and nothing a customer sees carries it.

1.12.1, 15 September 2026: the complimentary-access warning names the day the grant ends

• When an administrator of this service grants an account complimentary access for a fixed period, the warning returned by the admin surface (staff-only, not the account holder's own control panel) names the day the grant ends as a calendar day in London time, 22 September 2026, where it had interpolated a raw ISO timestamp with milliseconds into the sentence. The day is the one on a London wall clock rather than the UTC one, so a grant ending in the hour after midnight during British Summer Time is named for the day it ends there, not for the day before.

Unchanged: everything a customer or a connected client can observe. Every tool, every parameter, every result shape and the consent flow are as they were under 1.12.0; the sentence that changed is seen by an administrator of this service and by nobody else.

1.12.0, 15 September 2026: one connection per person over single sign-on, and what an invoice bought

• An exchange of an identity assertion at the token endpoint, the single sign-on route of 1.10.0, joins the person's existing connection instead of adding a new one every hour. The server looks for an unrevoked connection made by the same client for the same person on the same mailbox or share, from the same identity provider and subject, and rotates that connection's token in place; the mailbox's Connector tab then shows one connection per person through your identity provider, renewed at each exchange, where the live test of 15 September had listed the same person twice inside an hour (Claude's connection test, then the first chat). A revoked connection is never reused: the next exchange makes a new one, as before.
• A first payment for Team Access is thanked the way a first Pro payment already is. The account's owner receives an email with the subject "Team 3 is now on your account" (naming whichever tier was bought), with the tier, the seats and the day it renews, and where to invite people. It is sent on Stripe's first invoice for the subscription and never on a renewal, and it carries no price, because Stripe's own receipt does.
• GET /billing/invoices says what each invoice bought and whether it was refunded: kind (Pro or Team), tier on a Team invoice, the mailbox address on a Pro invoice, a mailbox since removed included, and state, which is refunded, partly_refunded or Stripe's own status. The refund state is read from the charges that settled behind the invoice's payments, so the control panel can say refunded, or partly refunded, on a payment that came back rather than paid. Stripe's status stays on every item as it was.
• POST /oauth/authorize/prepare, which the consent screen is built from, names the mailbox or the share the client's connector URL resolves to (request.mailboxId or request.shareId), so the consent screen can preselect the mailbox the client named rather than asking the person to pick it from the list. For the bare server address, a URL that is nobody's or a paused share, both are empty. The token endpoint and the consent screen now read the key out of a connector URL through one function, so they cannot disagree about which mailbox a URL names.

Unchanged: every tool name, every parameter and every result shape, the consent-screen flow and the levels and the limit under it, and every field the invoice list already carried. The reuse applies to the assertion exchange only; a connection made through the consent screen is issued and listed exactly as it was under 1.11.1.

1.11.1, 14 September 2026: a person held at enrolment can list the shares they may leave

• GET /shared-with-me answers a person the enrolment gate is holding, so they can see which shares they hold and leave one. Under 1.11.0 a person gated at sign-in (the owner switched on the second factor while they were away) could leave a share only by already knowing its id, because every read of their shares was refused in that session and the control panel could neither name the share nor build the form. The list a gated person gets carries the owner's display name and the addresses they were invited at, and never a connector key; every other route stays closed to them until they have an authenticator.

Unchanged: every tool name, every parameter and every result shape, and the gate itself: a person it holds can still do nothing but set up an authenticator, sign out, close their own account, or now list and leave the shares that put them behind it. No migration.

1.11.0, 14 September 2026: a browser-hosted client can connect, a shared person can leave, and 2 fields the panel asked for

• The MCP endpoint itself answers a browser's CORS preflight, so a client that runs in a browser (the MCP Inspector's browser transport, Okta's Cross App Access playground, a web-hosted agent) can connect. Until now the preflight met the bearer check first and was answered with a bare 401, so such a client could discover the server and mint a token and then not connect. A preflight is now 204 with POST, GET, DELETE, OPTIONS allowed and Authorization, Content-Type, Mcp-Session-Id, Mcp-Protocol-Version, Mcp-Method, Mcp-Name as the request headers; every other answer, the 401 included, carries the origin header and exposes Mcp-Session-Id and WWW-Authenticate, so the client can read the 401's resource-metadata hint. The origin is * with no credentials, as on the token endpoint, because nothing here is authenticated by a cookie and every request must carry a token the page already holds. Claude, ChatGPT and Claude Code call from their own backends and never send an Origin, so nothing changes for them.
• A person who holds a share of somebody else's mailbox can leave it: DELETE /shared-with-me/:shareId ends the share exactly as the owner's revoke ends it, every connection under it ended in the same transaction and its connector URL refused on the next call, the seat offered to whoever is parked. 204 with no body and no email; 404 share_not_found for a share that does not name the caller as its person. It is reachable by a person the enrolment gate would otherwise hold, because the accepted share is what gates them and leaving it is what lifts the gate.
• Two fields the control panel asked for. Each item on GET /oauth/grants carries idpIssuer and idpSubject, which identity provider and which subject at it minted the connection through single sign-on, and null on every connection made through the consent screen, so a panel can say "connected through your organisation's sign-on" from a fact rather than from the shape of the label. GET /admin/accounts/:id carries the account's two switches, requireTotp and auditRetentionDays (null for the default), on the detail and not on the list.
• The token endpoint's 429 from the flood guard is now the ordinary OAuth error shape, as every other refusal on that endpoint is.

Unchanged: every tool name, every parameter and every result shape. A client that never sends an Origin, which is every client that calls from its own backend, sees no difference. No migration.

1.10.0, 14 September 2026: single sign-on for a Claude Team or Enterprise organisation

• The token endpoint accepts the JWT bearer grant (grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, RFC 7523) carrying an identity assertion in the ID-JAG profile of the MCP enterprise managed authorisation extension, which is how Claude connects each person in a Team or Enterprise organisation with no sign-in and no consent screen (Anthropic's Enterprise Managed Auth). The client must be one this server fetched as a Client ID Metadata Document, which Claude's is; a client made by dynamic client registration is refused with invalid_client, because the identity provider stamps a fixed client id into every assertion. resource is required and must be the connector URL of one mailbox or one share, never the bare server; when the request omits it the assertion's own resource claim is used, and when both are present the claim must cover the request (invalid_target otherwise). The answer is an access token for 1 hour with scope: mcp and no refresh token; the client presents a fresh assertion when it expires.
• Trust is per account, and the owner sets it: GET and PATCH /account/sso carry the identity provider's issuer URL, an optional key set (JWKS) URL for a provider with no discovery document, and the switch. Switching it on needs Team Access (409 team_required, nothing changed) and an issuer (400 issuer_required); whenever the issuer or the key set URL changes or the switch goes on, the issuer's discovery document is fetched and must name it exactly with an https key set, or the change is refused as 400 bad_issuer with the URL and what was wrong (with a key set URL given, that key set is fetched instead and must carry keys, 400 bad_jwks_uri otherwise). Both verbs answer the account's setting and the 3 values a Claude administrator needs from this server: serverIssuer https://app.mailbox-mcp.com, tokenEndpoint https://mcp.mailbox-mcp.com/oauth/token and grantType. Trust is resolved through the resource: the owner of the mailbox the connector URL names must have registered the assertion's issuer and switched it on, or the exchange is refused before any key is fetched from anybody.
• The assertion is verified against the issuer's published keys and then on issuer, audience (this authorisation server's issuer identifier), expiry and issue time within 60 seconds, subject, email address, the presenting client and the token's type header, and its identifier is spent once, so a replay cannot mint. Every refusal is invalid_grant with one bare code word in error_description (issuer_not_trusted, bad_signature, expired, bad_audience, no_email, replayed and the rest), the detail in the server log; the one that carries a sentence is no_access, which a Claude administrator can be shown: alice@acme.com has not been given access to sales@acme.com. The account owner can add them under People.
• The mapping is by the connector URL and the asserted email address, and the level is the one the owner already set: on a mailbox's own URL the owner's confirmed account address is connected at the mailbox's limit, and an active share's invited address (or its person's confirmed account address) at the share's level and calendar; on a person's own URL, that share only; anyone else, and a paused, parked or unaccepted share, is no_access. There is no separate single sign-on level and no setting for one. The grant is listed on GET /oauth/grants for its hour like any other, labelled via <issuer host>, with the issuer and subject that minted it recorded on the row and shown nowhere; the verifier, the policy gate, the meter and the audit record treat it as any grant, so lowering the limit or pausing the share lands on its next call.
• The authorisation server metadata lists the grant under grant_types_supported and the profile urn:ietf:params:oauth:grant-profile:id-jag under a new authorization_grant_profiles_supported, on the API's constants and in the control panel's discovery document alike, which is how Claude discovers that the grant is offered.
• A flood guard now sits in front of every grant on the token endpoint, the consent-screen ones included: 300 requests a minute per address, keyed on the address the reverse proxy forwarded, answered 429 temporarily_unavailable with Retry-After in whole seconds once crossed, before any lookup, and logged once per address per window. The size is chosen with Anthropic's own egress in mind, which calls this endpoint for every Claude customer from a small range of addresses: 300 a minute from one address is 18,000 connections an hour, and a burst beyond it waits at most a minute.
• Verified live on 15 September 2026: a Claude Team organisation signing in through an Okta organisation, set up as the administrators' section of the Claude.ai page describes; Claude's own connection test passed all 4 of its steps against this server, and a member's chat read a mailbox with no consent screen. Before that, on 14 September, Okta's Cross App Access playground and the server's own tests. The set-up for administrators is on the Claude.ai page.

Unchanged: every tool name, every parameter and every result shape, and the consent-screen flow itself. An account whose owner has registered no identity provider, which is every account that existed before this release, behaves exactly as it did under 1.9.0: nobody is connected silently. The flood guard is the one thing every client now passes through, and its limit is sized for the egress that carries every Claude customer at once.

1.9.0, 14 September 2026: a second factor of everyone, and how long the audit record is kept

• An account's owner can require a second factor of everyone on the account: one switch under Settings, Security in the control panel (requireTotp on PATCH /account, off by default). It covers the owner and everyone holding an accepted share on one of the owner's mailboxes, a paused person included. Turning it on needs the owner's own authenticator confirmed first (409 enrol_first, nothing changed), and while it is on the owner's authenticator cannot be turned off (409 required_here), so an owner cannot lock themselves out by either door.
• A person the switch covers who has no confirmed authenticator is still signed in, with mustEnrolTotp: true on the sign-in and session routes, and is then refused every control route but the session read, sign-out, the 2 enrolment routes and erasing their own account, with 403 totp_enrolment_required and one of 2 sentences: This account requires a second factor. or An account that shares a mailbox with you requires a second factor. Accepting an invitation onto such a mailbox is refused the same way, before anything is written, so the link stays live and works once they have enrolled; GET /invites/:token says so in advance with requiresTotp.
• The requirement reaches AI connections, not only sign-in. The verifier that checks every OAuth-authenticated call reads the same definition of who must enrol, so such a person is refused at their share's connector URL and at the base URL alike, exactly as a suspended share is refused: an opaque 401 to the client, the reason in the server log. The mailbox's pasted access token is the mailbox's credential rather than a person's sign-in, never passes through that verifier, and is not gated. For a person with an authenticator the check is one read of their own row; for one without, it walks their shares on a partial index on mailbox_shares added for exactly that predicate, since the check now runs on every OAuth-authenticated call as well as on every panel request.
• The audit record is kept 400 days by default, and the account's owner may shorten it to any whole number of days from 90 to 400 (auditRetentionDays on PATCH /account; null is the default; anything else is 400 bad_retention naming the range, nothing changed). The nightly prune reads each account's number per row, through the row's mailbox to its owner, in one statement and never below the floor; a row whose mailbox has since been deleted keeps the default, because the record outlives the mailbox. GET /account carries both switches.
• The permission levels are stated by the API rather than known by the panel: POST /oauth/authorize/prepare and GET /oauth/grants carry levels[], most capable first, each with its label, description, the sentences a consent screen shows for it and how many tools it reaches; and every place a level id appears carries its words beside it as levelLabel and effectiveLevelLabel: each connection, each person and each of their mailbox rows, each mailbox shared with you, and the public invitation page. GET /people items also say totpConfirmed, whether the person has a confirmed authenticator (null while invited), which under the switch is also why their AI client has stopped answering.

Unchanged: every tool name, every parameter and every result shape. An account whose owner has touched neither switch, which is every account that existed before this release, behaves exactly as it did under 1.8.0, for the owner, for every person on it and for every connection to it.

1.8.0, 14 September 2026: the mailbox limit, under every connection

• Every mailbox carries a limit, set by its owner in the control panel on the mailbox's Connector tab: one of the 3 permission levels and the calendar switch, defaulting to Send and delete with the calendar on. It is the most any AI client may do with that mailbox. Every connection now acts at the lower of its own level and the limit, and has the calendar only when both say so; tools/list shows that effective set and tools/call refuses outside it, before the meter, as a level refusal always has.
• A pasted access token (Cline, Goose, LibreChat, n8n, and any client that takes a bearer token instead of signing in) takes the mailbox's limit as its level and calendar. Until this release it was fixed at Send and delete with the calendar, whatever the mailbox's connections were set to. With the default limit it still reaches everything; on a limited mailbox it is capped like every other connection.
• A consent cannot be approved above the limit, a person under Team Access cannot be invited or raised above it, and a connection's level cannot be changed above it: each is refused by the server with a sentence naming the limit and the mailbox, whatever a screen showed. A connection or a share already above a limit lowered since is capped on its next call and never rewritten, so raising the limit again restores exactly what was chosen.
• When the limit is what refused a call, the sentence names the limit rather than the connection, because the limit is the control the owner has to change: This mailbox is limited to "Read only" in the control panel, so no connection can send from it. The mailbox owner can change that under the mailbox's Connector tab. The activity record's note ends (mailbox limit) on such a row, and the server instructions a capped connection is handed gain a paragraph that opens by saying the mailbox is limited rather than the connection.
• The control panel API carries the limit on every mailbox (GET /mailboxes, GET /mailboxes/:id, changed by PATCH /mailboxes/:id), and the connections, people, invitation and shared-with-me lists carry the effective level and calendar beside the chosen ones, so a screen can say what a connection actually has and why.

Unchanged: every tool name, every parameter and every result shape. A mailbox whose limit has not been touched, which is every mailbox that existed before this release, behaves exactly as it did under 1.7.2 for every connection and for its access token.

1.7.2, 14 September 2026: Closing an account stops its Team Access renewal

• Closing an account (DELETE /account, or an administrator removing one) now stops the renewal on the account's Team Access subscription in the same call that stops each Pro mailbox's, before the account is removed. Until now the Pro renewals stopped and the Team one did not, so a closed account could have gone on paying for seats nobody could use.
• The four-times-a-day billing check now stops the renewal on any subscription whose account or mailbox has gone, Pro or Team, and says so once, instead of reporting the same orphan every run for the rest of its term.

Unchanged: every tool, every route and every result shape. Nothing changes for an open account.

1.7.1, 14 September 2026: Team Access on the admin surface, and fixes on the money paths

• The admin surface (staff-only, not the account holder's own control panel) now shows Team Access: four overview counts, a team column on every account row, a ?only=team filter, and the people on an account's own detail page. It is read-only there; nothing on this surface changes a plan, a seat or a payment.
• The first renewal after downgrading a mailbox now reads its term from the subscription line itself rather than from the proration Stripe generates for the change, so it renews for the plan actually held. A subscription cancelled with immediate effect keeps the seats already paid for until the date they are paid to, rather than losing them the moment the cancellation is confirmed.
• A Team renewal that fails at Stripe now has a visible state: GET /billing.team reports it, one email goes out, and the control panel shows a Billing caution rather than a tier that looks fine while the card behind it has failed.
• A second Team purchase for an account that already holds one is refused before it reaches Stripe, and if both webhook doors somehow deliver it anyway, it is cancelled and refunded automatically rather than left as a duplicate charge. Only one checkout can be open on an account at a time; starting a second for a different tier replaces the first rather than running alongside it.
• Deleting a mailbox now revokes every share on it through the same path a deliberate removal uses, so a deleted mailbox cannot leave a shared person's connection still working. Inviting somebody to the wrong account is refused with the invited address shown masked, not in full.
• A claim or an approval on a message now follows the message through the mailbox's own moves (a rename, an archive, a move to Junk, a deletion) instead of being left pointing at a message that has moved on. The support desk refuses a reply on a ticket that is already closed.

Unchanged: every mail and calendar tool, every parameter and every result shape, and every Team tool and Team billing route the previous release added. An account or a mailbox observing none of the above behaves exactly as it did under 1.7.0.

1.7.0, 13 September 2026: Team Access, people on a mailbox they do not own

• An account holder can give named people their own connection to a mailbox they own. Team Access is bought once for the account as a tier of 3, 5 or 10 people (£119.99 + VAT, £199.99 + VAT or £399.99 + VAT a year), on top of Pro per mailbox, and includes no mailbox. A person is invited by email address with a level, the calendar switch, a daily cap and a list of mailboxes; the invitation is accepted only by an account whose verified address is the one invited, and the refusal names both addresses. Each accepted person gets a connector URL per mailbox and a line of their own in the activity record: every activity item now carries actor, the person who made the call.
• A Pro mailbox's daily allowance is 1,000 calls multiplied by 1 plus the number of people active on it, and a person's own cap is a second count inside the same check, refused with a sentence that names the cap and the People tab. Removal ends every share and every connection the person held in one action, each connection on its next call; pausing refuses every call and keeps the settings; a person the tier no longer covers is parked, refused with a plain sentence, and seated again without re-inviting.
• 6 Team tools, registered only on a mailbox whose account has Team access: claim_email, release_email, assign_email and request_approval at Draft and file, list_pending_approvals and approve_and_send at Send and delete. A claim is the keyword $MbxClaim on the message and an approval request the keyword $MbxApproval on the draft, in the mailbox itself; who holds it is a record naming the mailbox, folder, message and person and never any content. Exactly 2 keywords for the life of a folder, because a Maildir folder holds at most 26. On a server whose PERMANENTFLAGS lacks \* every one of these says claiming or approval is unavailable and stores nothing.
• On a Team mailbox list_emails and search_emails carry heldBy on each item, and reply_email, forward_email, draft_reply and draft_forward open their result with one sentence naming the holder when somebody else holds the message, and still do the work. approve_and_send sends through the ordinary path: one Sent copy, the draft's own attachments and threading, the draft removed as a mail client removes one it has sent.
• 2 owner emails, both preferences under what we email you about, on unless turned off: the first time a shared person sends to a domain the account has not written to since Team Access began, through any mailbox (who, mailbox, domain, subject), and a Monday 08:00 London digest per person of sends, filings and reads over the week and the drafts awaiting approval. On an account with Team Access every successful send teaches a per-account table of domains, domains only and never addresses, kept while the account exists.
• Billing: GET /billing gains a team object; checkout, a previewed change (up invoices the prorated difference now, down credits the next invoice and names the people it would park, newest first, before anything is written) and cancel-renewal are 3 new routes. A full refund of the Team payment ends the tier the same day and parks everyone.

Unchanged: every mail and calendar tool, every parameter and every result shape on a mailbox without Team access, which lists byte for byte as it did: heldBy is absent there rather than null. A connection at any level on a single-person mailbox observes no change.

1.6.1, 13 September 2026: a refused tool names what it is

• A tools/call naming a tool no level has ever placed (a typo, a name the model made up, a retired tool) comes back as There is no tool called `x` on this connection., with the name quoted back, instead of the Send and delete level's sentence and a remedy the owner could not perform. Its audit row is an ordinary failure with no Not allowed on this connection: prefix, because there is no level at which it would work and no control the owner could change.
• The control panel's Failed Sends card stops listing a policy-refused send as a delivery rejection. That is a read of the same audit table rather than a wire change: a refused send is not a failed send.

Unchanged: every real tool at every level, every tool name and every schema, which is why this is a patch and not a minor bump. serverInfo.version reports 1.6.1 and the registry published it on the tag.

1.6.0, 13 September 2026: permission levels, per connection

• Every OAuth connection to a mailbox carries a permission level, chosen on the consent screen when the connection is approved: Read only (16 of the 37 email tools: listing, reading, searching, finding a contact, the checks, and the addresses it may send as), Draft and file (30: those plus drafting, editing a draft, filing, archiving, junk, flags, read state, creating a folder and minting an upload link; never send, delete or rename), or Send and delete (all 37). Each contains the one below it. Where the connection includes the calendar, the same level reaches 8, 13 or all 21 of the calendar tools.
• The calendar is a separate switch on the connection rather than a fourth level. Off, and no calendar tool is registered at any level; on, and the level's calendar list applies. A mailbox with no calendar connected stores the switch as off whatever was asked.
• Both are changed in the control panel, under the mailbox's Connector tab, and a change is obeyed on the client's next call with the token it already holds. Nothing has to be reconnected. The panel lists every connection with its level, its calendar switch and its label.
• A connection below the top level is shown only its level's tools in tools/list, and its instructions gain a paragraph naming what it cannot do and what to offer instead, so a model is never offered send_email and never spends a turn discovering it cannot use it.
• A tools/call for a tool outside the level is refused as an ordinary tool result: HTTP 200, isError true, and one sentence naming the connection, its level and where to change it. The refusal runs before the meter, so it costs none of the mailbox's daily calls, and the activity screen records it as a failed call with Not allowed on this connection: in front of the reason.
• A JSON-RPC batch body, an array rather than one request, is answered HTTP 400 with error code -32600 before any stage reads it. Until this release a batch was dispatched with no meter row, no audit row and no level check. Batching left the protocol in the 2025-06-18 revision, so no current client loses anything.
• Every connection that existed before this release was set to Send and delete with the calendar on, which is what it could already do, and its approval date is that of its oldest token. A connection at that level observes no change.

Unchanged: every tool name, every parameter and every result shape. A connection at Send and delete with the calendar on, which every pre-existing connection is, behaves exactly as it did under 1.5.0, and so does a client holding the mailbox's connector token as a bearer token: that token is the full credential and carries no level.

1.5.0, 12 September 2026: who really sent it, and what was hidden

• Every message read (read_email, read_thread, and the message around a read_attachment) carries authentication: what the receiving mail server concluded about the sender from SPF, DKIM, DMARC and ARC, as one verdict, and whether the From address is the mailbox's own. Read from the Authentication-Results header the receiving server wrote, on any provider that writes one.
• Every message read carries signals: named reasons the message reads as addressed to the assistant rather than the person, with the text quoted. Hidden text, comments holding prose, invisible characters, a folder or file on the reader's own computer named beside a verb, and "disregard your instructions" phrasing. Reported, never acted on and never blocked; a message that merely mentions an AI is not flagged.
• schedule_meeting, update_meeting, respond_to_invitation, propose_new_time, forward_event and set_out_of_office now carry the destructive annotation, joining cancel_meeting and delete_event, which already did, so a compliant client asks before running any of them. They were marked reversible on the argument that a cancellation reaches everybody an invitation did; the invitation has still been read, and that is what cannot be recalled.
• read_attachment names a file that is not what it claims: a program, a shortcut, a disc image, an encrypted archive, a macro-enabled document or a script is reported as exactly that, from its bytes rather than its name or declared type. A download link serves the file with the type its bytes have, as an attachment, with a sandbox policy and no caching.
• The 3 ways a message could end the content fence early are closed, and the fence carries a value chosen at the moment of reading. A refusal that has to quote a stranger's address (a diverging Reply-To) fences the quoted part.
• The audit record your control panel shows records a failed tool call as failed. Until this release every call had been recorded as successful whatever the tool returned, because the auditor never parsed the streamed response; every row before 19:35 BST on 12 September 2026 says "ok" regardless. Downloads and uploads are audited for the first time, as the message and a file count, never a filename.
• A calendar credential the provider now refuses (a Google permission revoked or lapsed, a calendar server refusing its app password) is shown in the control panel on the mailbox row, the calendar card and the overview, and the owner is emailed once. Mail is unaffected throughout. Before this release the calendar tools left the connection and nothing said so.
• A hostile-email corpus of 22 specimens, each with the verdict and signals it must produce, runs through the product's own reading code on every test run.

Unchanged: every tool name, every parameter, the mail tool count, and what a read returns for a message that carries nothing to flag: the new fields are additive and a client that ignores them sees the response it saw before.

1.4.0, 12 September 2026: reading what is inside a file

• read_attachment: what is inside one or more attachments, by the references read_email lists. A PDF, a Word document, a spreadsheet or a slide deck comes back as text; a photo as a picture; a scanned page or a signed letter as a picture of the page, so it is read the way a person reads it. Extraction runs on the server, in its own process per call with a memory ceiling and a clock, because the file was chosen by whoever emailed the customer.
• Every attachment listed by read_email also carries a short-lived download link, so an assistant that cannot hand a person the bytes can still hand them the file.

Unchanged: everything else. The mail tool count went from 31 to 32.

1.3.0, 5 September 2026: archive, junk, and a preview on every listing

• archive_email, mark_junk and not_junk: filing by role rather than by folder name, resolving Archive and Junk from what the mailbox declares, on up to 500 messages in one call. Marked destructive, as moving is, because filing is the same act under a friendlier name.
• list_emails and search_emails return the first line or 2 of every message, with quoted history and signatures stripped, so "what has come in?" is answered in one call rather than one call plus one for every message. The preview does not mark anything read.

Unchanged: every existing tool. The mail tool count went from 28 to 31.

1.2.0, 5 September 2026: the listing names Gmail and the calendar

• A registry-only release: the listing's description, which the registry caps at 100 characters, named IMAP and Microsoft 365 and never Gmail, and never mentioned a calendar while 21 calendar tools were shipping. It now names all 3 providers and the diary, and the calendar connection routes joined the metadata.
• The calendar tools themselves are deliberately not listed in the registry record, because they are registered only on a mailbox whose owner has connected a diary; listing them would promise a client tools it would not be offered.

Unchanged: the server itself. No tool was added or altered in this release.

1.1.0, 3 September 2026: drafts a mail client can open

• draft_reply and draft_forward: a reply or a forward filed in the Drafts folder rather than sent, threaded and quoted, the forward carrying the original's files, the original message left unmarked, so a person can open the draft in Outlook or webmail, change it and send it themselves.
• update_draft: rewriting a draft in place, so revising it does not leave the old version in Trash.

Unchanged: every existing tool. 3 additions, nothing removed.

1.0.0, 1 September 2026: the first publish

• The first version published to the official MCP Registry as com.mailbox-mcp/mailbox-mcp, with the domain proven by a record served from this site. The server had been live for a week before this; the version marks the listing, not the launch.
• The surface at this point: read, search, send, reply, forward, file, flag, and the bounce, receipt and deliverability checks, on any Gmail, Microsoft 365 or IMAP mailbox; the calendar tools on a Microsoft 365 mailbox whose owner approved calendar access.

Unchanged: nothing to compare against: this is the baseline every later entry is measured from.

21 September 2026: pictures for the Gmail and Hotmail routes, and an Outlook.com section

The Gmail connect page and the app-password guide now show the screens they describe: the Second steps card on Google's 2-Step Verification page, the App passwords page, the dialog that shows the 16 characters once, and the control panel's own Gmail form, all real captures from that morning, and the page Google shows when the setting is unavailable, recreated and captioned as such because no account of ours is in that state. The Microsoft page gained a section for a personal Outlook.com or Hotmail mailbox, where the sign-in succeeds and the mailbox then refuses until its IMAP switch is on, with a recreation of the Outlook.com settings panel showing where the switch is, and a troubleshooting entry for the message the panel shows.

21 September 2026: the first walkthrough video, on the Claude guide and the IMAP guide

A 6-minute screen recording of the whole journey, an account created, an IMAP mailbox added, the connector pasted into Claude and Claude answering its first questions, is on the Claude guide and the IMAP guide, first in each page's contents. It is shown as a still with a play button, and nothing loads from YouTube until it is pressed, which keeps both pages as fast as they were; each carries the video in its schema. The same video is offered in the getting-started emails from server 1.26.1, at the two points people get stuck.

19 September 2026: the directory band, above the footer on every page

Anthropic reviewed Mailbox MCP and listed it in the Claude directory on 18 September, and from today every page carries a band above the footer saying so: a plaque with Claude's own wordmark, the day of the review and the listing's address, and the robot holding the cup he was handed. The band is drawn from one list of directory listings, so a second plaque appears the day another directory publishes one; the ChatGPT listing is under review and appears nowhere until it is. The AI discovery files carry the same fact in a sentence.

17 September 2026: Outlook contacts on the Microsoft page, the hub diagram's third band, and version 5 of the data processing agreement

With server 1.16.0, the Microsoft 365 connect page gained a section on the Outlook contacts a Microsoft sign-in brings, the sixth row of its permissions table, and its first set of questions; the home page's hub diagram gained its third band, the address book, beside the mail and the calendar; and every page that had said a Microsoft mailbox could not take an address book says where its book comes from instead. Later the same day, with server 1.17.0, the data processing agreement moved to version 5, because a postal address joined the list of contact data processed, and the tool reference, the connect pages and the AI discovery files list it among what a card carries.

16 September 2026: the CalDAV and CardDAV connect page, and the address book across the site

With server 1.14.0, a fourth set-up guide beside the 3 mailbox pages: Connect a CalDAV calendar or CardDAV contacts, for a mailbox that signs in with a password and is given its diary and its address book by one address each. It names the address each common host publishes, explains the 401 an account password earns from a host that wants an app password, and shows the 2 control panel cards. The same day, the tool reference gained the address book as a fourth surface, and the privacy policy, the data processing agreement (version 3 that morning, and version 4 the same evening when the writes shipped under 1.15.0 above), the IT and security page and the AI discovery files say what is read from a book, what is written to it and on whose instruction, and for how long a card is held.

15 September 2026: the administrators' set-up, as it was walked live

The section for Claude Team and Enterprise administrators on the Claude.ai page was rewritten as the procedure verified that day on a live Claude Team organisation signing in through an Okta organisation: what it needs, the 7 steps across Okta, the Claude admin console and our control panel in the order they were taken, what a member then sees, and the verification note stating the date rather than what was left to do.

14 September 2026: a social card for every guide, and a scene on the IT page

Each of the guides now has its own image for social sharing and for its Article schema, lettered with the guide's title in the site's own typeface beside the scene the guide already shows, where every guide had shared one default card before. The IT and security page gained a scene of its own under access control, and 3 pages took a scene the site already had where it showed the page's subject exactly.

14 September 2026: the Product Hunt badge, served from this site

The footer names the Product Hunt launch of Tuesday 15 September and carries the badge from 8am UK time that day. The badge is fetched by our server and served from this domain, so no visitor's browser talks to Product Hunt unless they click it; the privacy policy says so, and a deploy check holds it to that.

14 September 2026: Team Access on the site, and pricing as 3 pages

With server 1.7.0, pricing became a hub with a page for one person and a page for teams selling the 3, 5 or 10 person tiers, with a Pricing menu in the navigation; the Team Access guide was published; the tool reference gained the Team tools as a third surface; and the terms, privacy policy, refunds page and this changelog were brought up to date with what a shared mailbox holds and costs.

13 September 2026: the trust surface

Three pages for the person who has to approve this at work: IT and security, which answers a vendor security questionnaire in the order it asks; the data processing agreement, a link rather than a request; and service status, read from a monitor on a different provider so it does not depend on the thing it reports on. The host and the country were named on the privacy policy the same day.

13 September 2026: pages for the administrators who approve third-party apps

For Microsoft 365 administrators and for Google Workspace administrators: the app by its public identifiers, every permission with what it is for, what it never does, and the tenant-wide approval path, written for an IT administrator who has never heard of the product and has just been asked to approve it.