Reference

How to read this, and how to check it

Every release here has 3 copies of its version number and they agree by construction. The server's own server.json carries it; the server reports it as serverInfo.version when a client connects, which most MCP clients show somewhere in their connector details; and the official MCP Registry lists every version published under com.mailbox-mcp/mailbox-mcp, with the date it was accepted. If the number your client shows is not the newest one here, your client is holding a cached copy of the connector; reconnecting refreshes it.

Every release is a minor or a patch bump, and those words are used the way the version scheme means them: nothing removed, no tool renamed, no parameter whose meaning changed, and a patch changes no tool or schema at all. A client written against 1.0.0 still works against the newest version here. What each one adds is listed; what it leaves alone is stated rather than left to be inferred, because "unchanged" is the part a person upgrading actually wants to know.

What this page does not list: copy corrections on this site, which each page carries in its own update log; and the count of calendar tools a given mailbox is offered, which depends on where its calendar lives and is explained on the tool reference. The mail tools are on every mailbox and their count is on that page too, counted from the server's own registration code rather than typed here.

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: <code>heldBy</code> 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 (12 of the 32 email tools: listing, reading, searching, finding a contact, the checks, and the addresses it may send as), Draft and file (26: 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 32). 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.

Before the registry

The server was built from 23 August 2026 and served real mailboxes from the end of that month, so a customer connected in August was on code that predates every version above. Nothing they connected to has been taken away since; that is what "minor" has meant at every step. The product rule that governed all of it is stated on how it works: a person must not be able to tell, from Outlook or webmail, that a message was handled by an assistant rather than by them.

Sources

The versions and dates above are the tags in the server's repository, read on 14 September 2026; the registry's own record of them is public and is the one to trust over this page if the 2 ever disagree.

• The official MCP Registry: every version of com.mailbox-mcp/mailbox-mcp A JSON list, one entry per version, each with its status and the date it was accepted.
• The tool reference The current surface, counted from the server's registration code rather than typed.
• The threat model What 1.5.0's sender verdicts and signals do and do not solve, attack by attack.