Proton Bridge MCP, and the problem with encrypted mail

Proton has no API for your inbox, and that is the product working rather than a gap in it. Here is the way round that keeps your mail on your own machine.

Proton doesn't give you an API for your mail. That isn't an oversight and it isn't a roadmap item, it's the product working exactly as advertised.

Proton encrypts your mail end to end. The only place a message is readable is on a machine that holds your keys, which means your machine. Any provider that could hand an assistant a tidy endpoint for your inbox would, by definition, be able to read that inbox itself. Proton can't. That's the thing you're paying them for.

Which leaves you stuck if you want help with mail. Everything that plugs an assistant into email assumes the provider can see the email, and the one provider you picked specifically because it can't see yours is now the one you can't automate.

Bridge is the piece that was already there

Proton Mail Bridge solves this for desktop clients and has done for years. It runs only on your computer, holds your keys, decrypts locally and then speaks completely ordinary IMAP and SMTP to your machine. Apple Mail and Thunderbird have talked to Proton this way for a long time.

If Bridge is already decrypting on your machine and serving plain IMAP to localhost, then anything that speaks IMAP can read your mail there. Including an MCP server.

That's the whole idea. Proton Bridge MCP is a small server that runs next to Bridge on your own computer. Your assistant asks it questions, it asks Bridge, Bridge answers from the copy that was decrypted locally. Nothing is uploaded anywhere and there's no account to make, because there's no service in the middle. I never see any of it. I couldn't if I wanted to.

What it actually does

It searches and reads, across one folder or every folder and label at once with duplicates collapsed. It pulls attachments out and reads them, including the text inside PDF invoices, which turns out to be most of what anyone wants from mail automation. It hands back an image attachment so the assistant can actually look at it rather than guess from a filename. It tags and files messages one at a time or in batches, and replies in thread with the threading headers set properly.

It also sends. That part needed thinking about.

The bits that are deliberately awkward

Anything that puts a message in front of another human asks you first, and it's a confirmation you can't talk it out of. Not a setting, not a preference you can flip once and forget, an argument the call itself has to carry every time.

There's a second path that needs no confirmation at all. Every sending tool takes draft=true, which writes the thing into your Drafts folder and stops. Nothing has gone anywhere, so nothing needs guarding, and you get to read it before you decide. Most days that's the one I use.

Attachments were the part I went back and forth on longest. Being able to attach a file is obviously useful. Being able to attach any file on the machine is how data walks off a computer, and the assistant asking to do it may be acting on a sentence it read inside somebody else's email. The allowed directory therefore defaults to one attachments folder, and widening it is a decision you make in your own config. An instruction sitting in an incoming message can't talk it into reaching somewhere else.

What it doesn't do, and what will catch you out

It's unofficial. Not affiliated with Proton, not endorsed by them, and it can break when they change Bridge.

Bridge itself is a paid Proton feature, so a free account can't use this at all. Bridge also picks its own port numbers, and people assume 1143 and 1025 because those are the ones in every write-up. Read the ones your Bridge is actually showing you.

The one that catches people out is that IMAP exposes messages, while the Proton web app shows you conversations. A "Re:" sitting in your inbox can be perfectly empty while the original three messages up the thread is the one carrying the PDFs. Ask about a conversation and you want find_thread, not the message you can see.

It's Apache-2.0 and the code is on GitHub. There's an install guide that's generated from the project README, so it can't drift away from what the code does, and a page of the questions people ask first.

It's free. It was built because I wanted it and it didn't exist, which is the same reason as everything else here.