Skip to content

External testing

Proton Safe MCP needs feedback from Linux users running the official Proton Mail Bridge. This test checks the complete first-use path without granting send, delete, or move capabilities to an MCP client.

Allow about 10 minutes for the core test. Use only benign test content and stop if any step would require sharing a credential, private message, or confidential attachment.

Before you start

You need:

  • Linux with Proton Mail Bridge installed, signed in, and running;
  • a Proton plan that supports Bridge;
  • Python 3.11 or newer (3.11 through 3.14 are tested in CI) and uv;
  • Claude Code, Cursor, or VS Code;
  • one harmless unread message that you sent to yourself for this test.

Record your Linux distribution, Python version, Bridge version, MCP client, and the time when you start. Never include your Proton password, Bridge-generated password, recovery phrase, 2FA data, email address, message content, or hardware-key material in public feedback.

Core 10-minute test

1. Install and configure

Install the reviewed release:

uv tool install proton-safe-mcp==2.3.0

Follow Getting started to set PROTON_BRIDGE_USER and PROTON_IMAP_PORT, then store the Bridge-generated IMAP password in the operating-system keyring:

proton-safe-mcp setup

Register the server using the instructions for Claude Code, Cursor, or VS Code.

2. Reach the first connected result

Ask the client to call mailbox_status. Stop the timer when the response reports connected: true and record the elapsed time.

Then ask it to call list_folders and list_messages for the inbox. Do not paste tool output into a public issue: it can contain private folder names, senders, and subjects.

3. Confirm that reading is non-destructive

Ask the client to call read_message for the harmless unread message you prepared. Open Proton Mail separately and confirm that the message is still unread. The server uses BODY.PEEK and should not change read state.

4. Exercise conversational confirmation

Ask the client to propose a plain-text draft addressed to your own Proton address. Use a neutral subject such as Proton Safe MCP external test and do not add an attachment yet. Confirm the exact recipient, subject, complete body, and empty attachment list in the conversation.

The client should call create_confirmed_draft with user_confirmed: true. Confirm that:

  • the draft appears in Proton Mail;
  • the recipient, subject, and body match what you confirmed;
  • the result reports sent: false;
  • the client exposes no send, delete, or move tool.

Review the draft manually and delete it in Proton Mail if you do not want to keep it. Do not send it merely for this test.

5. Confirm the draft tool refuses an unconfirmed call

Ask the client to call create_confirmed_draft with user_confirmed: false. The call must fail and no draft may appear in Proton Mail.

Optional reply-threading check

A reply target is refused by default. Proton Bridge reconstructs an appended draft without carrying the parent link, so the server will not create a reply draft it cannot honestly call threaded. How Proton then groups such a draft is the one behavior the test suite cannot settle, because it depends on Proton rather than on anything this server controls. Reports on this section are especially useful.

Ask the client to reply to the harmless message you prepared. It should call get_reply_context, which reports threading_supported: false and a threading_notice, then present the candidate recipients and a suggested Re: subject. Confirm that:

  • the client explains the threading limitation before asking you to confirm any content;
  • passing the reply target without allow_unthreaded_reply: true fails with reply_threading_unsupported, and no draft appears in Proton Mail;
  • the client offers the Proton Mail Reply or Reply all workflow instead, rather than dropping the reply target or setting the flag on its own.

If you then explicitly accept a draft that may appear separately, let the client retry with allow_unthreaded_reply: true and confirm in Proton Mail that:

  • the recipient is the one you confirmed, not one the client chose from the message's headers;
  • the body is exactly what you confirmed, with no quote the server added on its own;
  • the result reports threading_verified: false, and the client does not describe the draft as attached to the conversation.

Finally, record where the draft landed: inside the existing conversation, or as a separate message. Expect separate. The RFC threading headers this server sends are correct, so a draft that does land inside the conversation would tell us Proton groups appended drafts by something other than the parent link. Note whether the subject carried a Re: prefix, since subject-based grouping would explain it. Both outcomes are worth reporting: this is the evidence that would let the default refusal be relaxed.

Also confirm the reverification refuses a stale target: ask the client to create a reply whose reply_to_message_id is a value you altered by hand. The call must fail and no draft may appear.

Optional attachment check

If the core test succeeds, repeat the draft flow with a newly created, non-confidential TXT or PDF file. Follow the attachment workflow and confirm that the file name, type, size, and SHA-256 digest are checked before the draft is created.

Never use a personal document for this test. Attachment handling depends on the MCP client's ability to obtain bytes and call the chunked upload tools, so record any client-specific friction.

What success looks like

The core path is successful when:

  1. mailbox_status reports connected: true in ten minutes or less;
  2. reading the prepared message does not mark it as read;
  3. direct draft creation occurs only after exact conversational confirmation;
  4. the confirmed draft appears in Proton Mail and is never sent;
  5. bounded PDF/TXT/CSV text extraction returns no raw bytes or filesystem path;
  6. no send, delete, move, or raw received-attachment-download tool is exposed;
  7. a reply target is refused until you explicitly accept a possibly separate draft, and an accepted reply draft carries the recipient and body you confirmed and reports threading_verified: false.

Partial and failed tests are equally useful. Report the first point of friction rather than working around it silently.

Send installation feedback

Open the installation feedback form and report the outcome. Redact all identifiers and message content. For a suspected security vulnerability, do not open a public issue; use private vulnerability reporting.