Your AI Subscription Can Already
Run Your Inbox

You pay for an AI subscription. You use it for writing, for code, for talking through a problem at eleven at night. Somewhere else entirely, you spend a couple of hours a day in your inbox doing work that is mostly sorting, chasing and answering.

Those two things have never met, and most people assume the reason is that the AI can't do it. That stopped being true a while ago. The connection exists, it is built into the plan you already have, and almost nobody has been told.

Here is the proof, with a timestamp on it. On 1 September 2026 we connected a real mailbox to a ChatGPT Plus account at 20 US dollars a month, in an ordinary web browser, and asked it to send an email. It arrived at 08:27, from sales@365i.co.uk, carrying the full HTML signature. OpenAI's own FAQ says full MCP support is for Business and Enterprise or Edu, and that Pro users get read and fetch permissions in developer mode. It does not mention Plus at all. So that measurement is past the documentation twice over: on the price tier, and on the fact that it wrote rather than only read.

The AI subscription capability you are already paying for

The mechanism is called the Model Context Protocol, or MCP. Anthropic published it in November 2024 and then, unusually, gave it away rather than keeping it. It is now the way assistants from several vendors talk to outside systems, and the important consequence for you is that it turned "can this AI use my tools" from a question about the vendor into a question about you.

A remote MCP connector is the simplest version of that. It is a URL and a token. You paste them into your AI client, and from that point the assistant can see a list of named tools and call them. Nothing is installed. There is no plugin, no browser extension, and nothing running on your computer.

Anthropic's support documentation is unambiguous about who gets this: "Custom connectors using remote MCP are available on Claude, Cowork, and Claude Desktop for users on Free, Pro, Max, Team, and Enterprise plans." Free users are capped at one custom connector. Everyone paying gets more than one. If you have Claude Pro, you have had this the whole time.

ChatGPT is messier and the honest answer has two halves. OpenAI's published position is that full MCP support belongs to Business and Enterprise or Edu, with Pro limited to read and fetch permissions in developer mode. Our measurement says Plus reached a custom server and called its write tools on 1 September 2026. Both of those are true at once, and a reader on Plus needs both: it works today, and OpenAI has not promised it will keep working. We report the measurement and the vendor's wording side by side rather than choosing between them.

Beyond the two big chat clients, the list is longer than most people expect. Claude Desktop and Claude Code, Microsoft Copilot Studio, Cursor, VS Code, Zed, Cline, Windsurf, Goose, LibreChat and n8n all take a remote MCP server, and there are thirteen written setup pages, one per client, plus ten task guides covering triage, replies, filing, search and calendar scheduling. The screen names differ in every one of those clients, and a generic README helps nobody at the moment they are stuck on the wrong menu.

What connecting a mailbox to your AI actually means

When you connect AI to your email this way, the assistant is handed 28 email tools. Not 28 features in a marketing sense: 28 named functions it can call, each with a defined input and a defined result. Every mailbox gets the same 28, whoever hosts it.

A connected calendar adds more, and this is where the number needs a condition attached to it rather than a footnote. Up to 21 calendar tools, and "up to" is doing real work: a Microsoft 365 mailbox with calendar access approved is offered all 21, Google Calendar answers for a subset, and a CalDAV server is offered as many as it actually implements, measured when it connects. So the largest surface anyone gets is 49 tools on a Microsoft 365 mailbox, and the honest general statement is 28 plus however many your diary can support.

It is worth being equally clear about what this is not. Nothing here runs unless a client calls it. There is no rule engine, no background process reading your mail, and nothing watching the inbox to act on its own. An assistant does something because you, or a workflow you built, asked it to. If you want an autopilot, this is the wrong shape of product.

It is also not a general connection to your digital life. Beyond mail and a connected calendar there is nothing: no contacts list past resolving an address from your own correspondence, no files on a drive, no tasks. That narrowness is the point, and it is the same argument this site makes about AI visibility generally. A machine works well against explicit, declared capability and badly against inference. Publishing what you can do, precisely, beats hoping something guesses right, whether the thing publishing is a website's discovery files or a mail server's tool list.

Nine things to try on your own mail tonight

Each of these is a real request with the tools that answer it and roughly what it costs in calls. One MCP call is one tool run. The counts are honest ranges rather than a specification, because how many calls a request costs depends on how the model chooses to work, and two assistants answering the same question will not spend the same number.

1. Triage a weekend backlog without marking anything read

Ask it to go through your unread mail and tell you which ones actually need you. It lists, opens the ones it has to judge, and gives you a shortlist with the ones that need a human held back rather than answered.

The part that matters is what it does not do. Reading never sets the seen flag, so every message it looked at is still unread when you open Outlook. An assistant that marks eighty messages read while triaging them has destroyed the only signal you had, and there is no undo at that scale. Tools: list_emails, read_email, search_emails. About 2 to 10 calls.

2. File 400 messages into a folder in one call

The write tools take a set rather than one message at a time. Flagging, marking read, marking unread, moving and deleting all accept up to 500 messages in a single call, so a filing session over four hundred newsletters is one metered call rather than four hundred. At 500 messages a call, measured against a real server, move_email took 187 ms and delete_email 175 ms.

A heavy tidy-up is one of the cheapest things you can do here, which is the opposite of what most people assume. Tools: search_emails, move_email. About 3 to 6 calls.

3. Answer "did that actually arrive?" as two questions

This is the one people are most surprised by, because it is not a mail client feature at all. "Did it arrive" is really two questions and they have different answers.

Delivery is check_bounces: it looks for failure reports in the Inbox and in Junk, which is where a good proportion of them land, and it says whether each failure is permanent or temporary. That distinction is the whole point, because resending fixes a temporary failure and simply duplicates a permanent one. Reading is check_receipts: delivery confirmations meaning the recipient's server accepted it, and read receipts meaning their mail program reported it opened. It also says in the result that a missing receipt is evidence of nothing, because most mail programs never send one and most people decline when asked. 1 to 2 calls.

4. Find the address of someone you emailed 18 months ago and cannot name

"What is the email address for the woman at the surveyors? I think her name is Ada something." It resolves the person from the mailbox's own correspondence rather than from a contacts list nobody has maintained since 2019.

There is a small anti-phishing measure hiding inside that convenience: an address you have sent to outranks one that merely arrived from somebody using that name, because a display name on inbound mail can say anything at all. The address you have actually written to is the one you trusted before. Tool: find_contact. 1 call.

5. Send a reply that stays inside its own thread

It replies inside the original conversation, quotes the original below the new text the way a mail client does, files the copy in Sent, and marks the original as answered so your own client shows the little reply arrow next to it.

One safety rule worth knowing: a Reply-To header pointing somewhere the message did not come from is refused until the caller names that address explicitly. That header is how a redirected reply ends up somewhere you did not intend, and it is set by the sender rather than by you. Tools: read_email, reply_email. About 2 calls.

6. Forward a thread with its attachments carried across

The original's attachments and inline images travel with it, under the forwarded-message block a real mail client produces. If a carried file will not fit inside the 10 MB message ceiling, it is reported as skipped by name rather than dropped quietly, so you find out while you can still do something about it. Recipients are exactly the addresses supplied: nothing is inferred and nothing is added. Tools: read_thread, forward_email. About 2 to 4 calls.

7. Check SPF, DKIM, DMARC and MX from a chat window

Ask whether your domain is set up so your mail gets trusted. It checks the connected mailbox's own domain and says what is there, including the case that catches most people out: a DMARC record set to p=none, which looks like a configured domain and is publishing a policy that does nothing.

It also keeps a failed lookup apart from a missing record, because "we could not check" and "it is not there" are different problems with different fixes, and conflating them is how somebody spends an afternoon adding a record that already existed. Tool: check_deliverability. 1 call.

8. Write a real draft into the real Drafts folder

"Draft a reply to this, but do not send it." It is APPENDed to the mailbox's own Drafts folder, so it appears in Outlook, in webmail and on your phone, and you can edit it there, send it there, or delete it. A draft you can only see in a chat window is a record of a draft rather than a draft. Tools: read_email, draft_email. About 2 calls.

9. Find an hour everyone is free, and book it

"Find an hour next week when Priya, Tom and I are all free, and book it with a Teams link." It reads everybody's free and busy blocks, picks an hour inside all three working days rather than one that is merely empty at seven in the evening, creates the meeting with an online link, and sends the invitations.

Watch what it does when it cannot see somebody: that person comes back as unknown rather than free, and it says so instead of booking over an afternoon it could not read. This one needs a Microsoft 365 mailbox with calendar access approved. Tools: check_availability, find_meeting_times, schedule_meeting. About 3 to 5 calls.

Seven slightly frivolous things an AI email assistant can do

The complaint you see everywhere is that we asked for AI to do the laundry and the dishes so we could make art, and got it the other way round. Email is the dishes. Nobody grew up wanting to file newsletters.

So here are seven things that are not productivity, exactly, but are the ones people actually run first and then read out to somebody. All of them are real tools rather than a bit I made up for the article.

• Count how many times you have written "as per my last email". One search_emails call against your Sent folder. It is a number, it is yours, and you cannot un-know it. The passive-aggressive cousins work too: "just circling back", "gentle nudge", and "sorry for the slow reply", which for most people is the winner by a distance.
• Find out who you actually email, as opposed to who you think you email. Ask for your top correspondents over the last year. There is usually one supplier nobody would have guessed sitting at number three, and one friend you would have sworn you were in touch with sitting nowhere at all.
• Discover the oldest unread email in your inbox. Search on read state, sort ascending, brace. Mine was from 2019 and was, I promise, someone offering me work.
• The petty one, and it really is built in. check_receipts reads read receipts, and when a receipt reports that your message was deleted unopened, it reports that back as exactly that. No softening. You did ask.
• Audit your own domain and find out the lock has no bolt in it. check_deliverability flags a DMARC record set to p=none, which is the email equivalent of a very serious sign on a door that is not attached to anything. Roughly everybody who has "sorted out DMARC" has this.
• Count the newsletters you have never once opened, then file all of them in a single call. Up to 500 at a time. There is a specific and slightly shameful pleasure in watching four hundred messages leave an inbox in under two hundred milliseconds.
• Draft the reply you want to send, then the one you will send. Two draft_email calls, both landing in the real Drafts folder, neither of them going anywhere. The first is a stress-relief exercise. Delete it from Outlook like a grown-up.

A word of warning on that last one, and on this whole section. Every tool that sends is classified destructive for a reason, and "destructive" here means irreversible rather than damaging. There is no unsend. The old joke is that the fastest way to spot a typo is to press send, and an assistant that can press send for you does not change that law of nature, it just gets you there quicker.

The other joke worth retiring is the one about AI taking your job. Having watched this thing file four hundred newsletters in one call and then correctly decline to answer an email that needed a person, my honest view is that it is coming for the part of your job you would happily give away and stopping politely at the part you are actually paid for. The use cases page has the full set with a call cost against each one.

Why the shape of the tools decides whether any of it works

The count is the hook. The reason it works is the shape.

Every tool in that list is an email-user operation rather than an API endpoint. That distinction sounds like an implementation detail and it is the difference between a mailbox that behaves and one that quietly corrupts itself. reply_email exists because the alternative is expecting a language model to assemble In-Reply-To and References headers correctly, and a reply that carries a "Re:" subject with no threading headers is a forgery of a reply: it arrives as a brand new conversation, and nobody notices until the thread does not group. check_bounces exists because the alternative is asking a model to "search for messages that look like they came from a delivery subsystem". find_contact exists because the alternative is an address book and a guess.

Anthropic wrote the canonical version of this argument, and the example they chose is almost exactly ours:

"Instead of implementing a list_users, list_events, and create_event tools, consider implementing a schedule_event tool which finds availability and schedules an event."

Ken Aizawa, engineer at Anthropic, in Writing effective tools for agents, 11 September 2025 (verify quote at source)

I read that months after we had already built schedule_meeting, and my honest first reaction was relief rather than insight. We had arrived at it the slow way, by watching a model be handed three primitive calendar tools and reason its way to a booking that was technically correct and socially wrong, and it is oddly reassuring to find the people who designed the protocol had written down the same conclusion first. What sharpened it for me is the sentence's quiet implication: the primitive version works. Every one of those three calls succeeds. The model gets a plausible answer every time, and the failure only shows up as a meeting nobody can attend. That is the whole problem with judging these tools by whether they return without an error.

You can watch the difference in the wild. Google's own Calendar MCP server ships delete_event. We ship delete_event too, and it refuses the moment anybody else is on the event, naming cancel_meeting instead, because deleting a meeting other people hold removes it from your diary while everybody else carries on holding the time. Nobody gets told. It is not a bug in either product; it is a decision about whether the tool is shaped like the database row or like the thing a person meant.

The rule: you should not be able to tell that AI did it

There is one sentence in the project's own engineering notes that everything else follows from:

"A user must not be able to tell, from Outlook or webmail, that a message was handled by us rather than by them."

The reason it is written down is that the convenient implementation is reliably the wrong one, and the damage is invisible to us and obvious to you weeks later, somewhere else. A bug that files no Sent copy is invisible to a test written against the code that failed to file it. So acceptance ends in a mail client rather than in a green test run.

That produces six concrete promises, and they are the checkable part. Each one matters to an ordinary person the following week:

That last one sounds like pedantry until you meet a German mailbox where the sent folder is Gesendete Elemente and a tool that guessed the name has been silently filing nothing anywhere.

Here is that rule deciding something, on the afternoon this article was being written. A draft could always be changed: you saved a new one and deleted the old. But delete moves to Trash by design and never erases, so somebody reworking a draft four times finished with four dead drafts sitting in the folder they check before emptying it. Every one of those revisions was correct. The mailbox was still wrong, because no mail client has ever behaved that way, and by the rule above that makes it a failure rather than an inconvenience.

The fix shipped as a 28th tool, update_draft, and the interesting part is what it could not do. IMAP has no edit: RFC 3501 makes a message immutable once filed, and RFC 8508 added a REPLACE command for exactly this job which is unavailable on the two counts that matter, since the IMAP library does not implement it and Gmail does not advertise it. So an edit is write-the-new-one and remove-the-old, which is precisely what Outlook, Thunderbird and Apple Mail each do when you edit a draft and save it. Doing the same unglamorous thing is the whole point. It is also the only place in the product that removes something permanently on your behalf, which is why it is classified destructive alongside sending, and why it refuses outright if the message you pointed it at is not actually a draft.

Built so you can undo it, one mailbox at a time

The 28 email tools are classified: 11 read, 9 reversible, 8 destructive. The calendar's 21 split 8 read, 11 reversible and 2 destructive. Those classes are not decoration. They travel to your client as MCP annotations, which is what lets a host application stop and ask you before the consequential ones and stay out of the way for the rest.

Anthropic describes exactly that pattern, using the example this article has been circling all the way through:

"This means users can, for example, decide it's always safe for Claude to read their calendar, but still require approval before sending someone an invitation."

Anthropic, in Building trustworthy agents, 9 April 2026 (verify quote at source)

What strikes me about that sentence is how ordinary it is, and how recently it would have been unsayable. Two years ago the argument about AI and your data was all or nothing: either you handed a system your inbox or you did not, and the interesting question was whether you trusted the vendor. This reframes it as something much more like the permissions you already understand from your phone. The bit I keep coming back to is that they chose reading a calendar as the safe example, because reading a diary tells you a great deal about somebody and is still obviously less consequential than sending on your behalf. Getting that gradient right, rather than arguing about whether AI should touch your data at all, is the more useful conversation, and it is one the industry took an oddly long time to start having.

The other structural decision is that it is one connector per mailbox, each with its own URL and its own token, and I want to state that as a decision rather than let it look like a limitation we are hoping you will not notice.

The alternative design is a single connector with a mailbox argument on every tool. It looks tidier and it is worse, because it makes the model choose which account a message is sent from. For an email product that is the worst failure available: replying from the wrong identity, moving a client's thread into a personal account, sending from a personal address to a business contact. Carrying the mailbox on the connection deletes the whole class of error, because there is no argument to get wrong. A leaked token opens one mailbox rather than your entire mail estate, and revocation is per mailbox without touching the others.

The cost on our side was measured rather than assumed: baseline Node is around 60 MB and each additional live IMAP connection came in at 0.3 MB, so memory stops being the constraint long before mailbox count does. The cost on your side is real and worth stating plainly: no single call can span mailboxes, so "search all my accounts" is one call per connector, and you paste a URL and a token once per mailbox instead of once.

Calendars: three routes, and what each one actually answers

Connecting a mailbox does not connect a diary, because they are separate services. There are three ways in.

Microsoft 365 is the full surface. Calendar access is approved on the same sign-in as the mail, and all 21 tools are offered, including the ones nothing else in this comparison expresses: propose_new_time, which declines an invitation and suggests an alternative in the same action, and set_out_of_office, which writes the same setting Outlook writes so it shows in Outlook and switches itself off at the end of the period.

Google Calendar is one sign-in and answers for a subset. There is a live caveat here that I would rather you heard from us than met on the screen: our Google verification is under review at the time of writing, so anyone taking the Google route currently meets Google's "hasn't verified this app" warning during sign-in. It is Google's standard unverified-app screen rather than anything wrong with the connection, but it looks alarming if it arrives unannounced.

CalDAV is the third route and the one that covers everyone else: Fastmail, iCloud, Nextcloud, and the many mail hosts that quietly run a calendar server alongside the mail one. You give the address of your calendar server. Capability is then detected per server rather than assumed, by asking that server what it can actually do, which has an honest consequence: two customers on two CalDAV hosts can be offered different calendar tool lists and both be right. A server that cannot tell anybody about a meeting is not offered the tool that books one, which is better than offering it and failing at the moment somebody is waiting on an invitation.

How the email MCP servers compare

Every competitor figure below was re-verified against live vendor documentation on 3 September 2026, because these numbers move monthly, and each is linked so you can check it yourself. Our own column is derived from the two source files that register the tools, not typed from memory, which matters because our column is the one most likely to be wrong: competitor cells get researched and your own get remembered.

One caveat on counting, because it cuts against us as much as anyone. Nylas publishes 38 tools covering mail, calendar, contacts, time conversion and its Notetaker product, and splitting that into "mail" and "calendar" is our judgement rather than their labelling. Two careful readings of the same page here produced 13 and 14 for mail, depending on whether a search-syntax helper counts. Treat the middle rows as the reliable ones: what a tool is called is a fact, and how you file it is an opinion.

Two things in that table deserve saying out loud rather than leaving in a cell.

Google's Gmail MCP server cannot send an email. Its ten published tools are create_draft, list_drafts, get_message, get_thread, search_threads, list_labels, and label and unlabel for messages and threads. The closest thing to sending is creating a draft you then send yourself from Gmail. That is a deliberate, defensible product decision about review-before-send, and it is a decision you should know about before you assume the official option is the complete one.

MailMCP.io has scheduled send and we do not. Their schedule_email, list_scheduled and cancel_scheduled tools do a thing our 28 cannot do at all. If writing at midnight and having it land at nine is the feature you actually want, they have it and we do not.

Two more competitors do not fit the table and are worth naming honestly rather than leaving out.

Composio beats us on raw action count, and it is not close. Their Gmail toolkit publishes more than 60 actions, and their Outlook toolkit is several times larger again. If your measure is how many distinct operations you can reach, we lose that comparison outright. Our argument is not "more actions", it is "actions shaped like the job", which is a different claim and one you should test rather than take from an interested party. Composio is also a different kind of product: a broad toolkit platform across hundreds of services, rather than one mailbox done deeply.

Kai, from the Morgen team, is not really in this category and is a fair competitor to the whole idea. It is a finished assistant rather than a connector you attach to a subscription you already pay for, and its published position is a deliberate one: "Send is always your click", and "Nothing sends or moves without your sign-off." That is a coherent product philosophy, not a missing feature, and for a lot of people it is the right answer. If you want an AI that triages and drafts and never acts, a tool surface with seven destructive operations on it is not what you are looking for.

What Mailbox MCP cannot do, and what it costs

A list of things a product cannot do is more useful than another list of things it can, so here is ours in full.

There is one more limit that is not ours to fix, and anybody handing an assistant a live inbox should hear it. Email is attacker-controlled text. Anyone can send you a message, and a message can contain instructions aimed at the assistant reading it rather than at you. That is the prompt-injection problem, it is not solved, and no tool design makes it go away. What tool design can do is bound the damage: nothing here erases mail, delete is recoverable, each connector opens one mailbox, and the seven destructive operations are annotated as destructive so your client can stop and ask. Approve write actions rather than automating them, and be more careful the further you get from mail you expected.

On price: £34.99 + VAT per mailbox per year. The figure is always drawn with its VAT qualifier because a bare number next to a published VAT registration is a claim about the total, and VAT depends on where the buyer is. One account can hold as many mailboxes as you like with Pro on any subset of them. Full detail is on the pricing page, and the use cases page publishes a call cost against every scenario, which is a number nobody else in this market publishes at all.

How to connect a mailbox to your AI assistant

Fifteen minutes, most of which is the mailbox rather than the AI.

The wider point, and why this site is writing about email at all

This site exists to argue that AI systems work well against explicit, machine-readable declarations and badly against inference. That argument usually gets made about websites: publish what you are and what you do in a form a machine can read, rather than hoping something works it out from your homepage copy. The AI Visibility Checker exists to test whether a site has done it, and the ten things a website must publish is the long version.

A mail server turns out to be the same argument in a smaller box. Twenty-seven declared operations with defined inputs and defined consequences will beat one clever tool and a model doing its best, for the same reason a declared identity beats a guessed one. The thing that has changed in the last two years is not that AI got better at guessing. It is that we started giving it things it does not have to guess about.

If you are working out which subscription to hold in the first place, our comparison of what each AI subscription costs and what it is worth covers the buying decision, and which AI tool to use for which job covers the one after it. If you want the model side of this rather than the plumbing, Claude Opus 5 checking its own work looks at what changes when a model verifies before it reports back, which matters rather more once it is holding your inbox. And if you want the thing this site does for a living, preparing a website for AI agents and how AI search actually works are the two to read next.

Two last practical notes. If you run the websites as well as the mailboxes, 365i does the hosting and infrastructure side and 365i Web Design builds the sites, and if you have already published your discovery files you can submit your site to the directory for free verification and a public score.

Frequently asked questions