Proton Mail MCP Server

A Model Context Protocol (MCP) server that gives AI assistants full access to your Proton Mail account -- send, read, search, and organize email over SMTP and IMAP.

⚠️ Unofficial — not affiliated with Proton. This is an independent, community-built project. It is not developed, endorsed, sponsored, or supported by Proton AG. "Proton", "Proton Mail", and "Proton Mail Bridge" are trademarks of Proton AG, used here only to describe interoperability. It talks to Proton Mail over the standard SMTP submission endpoint and the locally-run Proton Mail Bridge; no Proton private API is used. Use at your own risk.

Demo

Related MCP server: protonmail-mcp-server

Features

• Send, reply, and forward email via Proton Mail SMTP with threading headers; dedicated reply_all_email tool

• Markdown bodies -- pass markdownBody to send_email / reply_email / reply_all_email / forward_email; rendered to HTML with a plain-text fallback

• Read email via IMAP through Proton Mail Bridge

• Attachments -- send files (base64), download to memory or to disk (saveTo + ALLOW_FILE_DOWNLOAD_DIR), forward a subset by part number

• Search messages by sender, recipient, subject, body, date, flags, size, List-ID, attachment presence, attachment name (substring), and attachment MIME type

• Organize -- move, delete, and flag/unflag messages individually or in bulk; bulk-update labels too

• Bulk operations -- bulk_move, bulk_delete, bulk_update_flags, bulk_update_labels with dryRun preview and XOR uid/match input

• Folder & label management -- create_folder, create_label, rename_folder, delete_folder (non-destructive on Proton); empty_folder (opt-in via ALLOW_EMPTY_FOLDER=true; not recommended)

• Labeling -- update_message_labels adds and removes Proton labels on a message (additive — message stays in its source folder)

• Aggregations -- count_messages, folder_stats, top_senders (with excludeSelf + per-row direction) for inbox analytics

• Thread mutations -- move_thread, delete_thread, flag_thread with optional cross-folder walk; get_thread dedupes by Message-ID across mailbox copies

• Snippets -- optional includeSnippet on list_messages and search_messages for at-a-glance previews

• List folders with message and unread counts

• Honest accounting -- post-STORE FETCH verify on flags/labels surfaces silently-dropped operations as notApplied; sent-copy lookup retries SEARCH to defeat Proton's index lag; Reply-To rewrites are surfaced in the send response

• Safety first -- delete moves to Trash by default (via special-use resolver), read-only mode via READONLY=true, dryRun on all bulk ops, MCP tool annotations for client-side confirmation prompts, path-traversal defense on filesystem-touching tools

• Security hardened -- input validation, credential sanitization, rate limiting, attachment size limits

• Works with any MCP-compatible client (Claude Desktop, Claude Code, Cursor, etc.)

Prerequisites

• Node.js v24+

• A Proton Mail account with an SMTP password (how to get one)

• Proton Mail Bridge running locally (required for IMAP/read tools)

Quick Start

Add to your MCP client

Add the following to your client's MCP server configuration (Claude Desktop, Claude Code, Cursor, etc.):

{
  "mcpServers": {
    "protonmail": {
      "command": "npx",
      "args": ["-y", "proton-mail-mcp"],
      "env": {
        "PROTONMAIL_USERNAME": "your-email@protonmail.com",
        "PROTONMAIL_PASSWORD": "your-smtp-password"
      }
    }
  }
}

That's it — npx will download and run the server automatically. See Configuration for all available environment variables.

Install from source

If you prefer to run from a local clone:

git clone https://github.com/sethbang/proton-mail-mcp.git
cd proton-mail-mcp
npm install
npm run build

Then use this MCP config instead:

{
  "mcpServers": {
    "protonmail": {
      "command": "node",
      "args": ["/absolute/path/to/proton-mail-mcp/build/index.js"],
      "env": {
        "PROTONMAIL_USERNAME": "your-email@protonmail.com",
        "PROTONMAIL_PASSWORD": "your-smtp-password"
      }
    }
  }
}

Tools

Sending

All send tools return the Message-ID of the sent message in their response, which can be used to locate the message via IMAP search. All four send tools (send_email, reply_email, reply_all_email, forward_email) perform a best-effort lookup of the sent copy UID in the resolved \Sent folder (retried across ~30s to defeat Proton's indexing lag) and lead the response with a machine-parseable token prefix — [sent-copy:verified] or [sent-copy:unverified], plus [reply-to:preserved|rewritten|stripped|unverified] when replyTo was requested. Agents can grep these tokens instead of text-matching prose. When the Sent-copy lookup converges, the response also includes a Sent copy UID: N in Sent clause; when it doesn't, the leading verb switches from "X sent successfully (Sent-copy verified)" to "X send accepted by SMTP (Sent-copy unverified within the lookup window)" — the message did go out, but per-delivery verification couldn't be completed within the budget.

🛡️ HTML sanitization defaults to ON (since v1.0.0). Send / reply / forward / save_draft tools strip <script>, event handlers, inline style attributes, and remote <img> beacons via a conservative allowlist before delivery. Pass sanitizeHtml: false to preserve full-fidelity HTML for trusted-content workflows. The success response notes when sanitization ran.

⚠️ Display-name spoofing partially defended. As of v1.0.0, fromName rejects values containing @ by default — without this guard, a fromName like "Anthropic Security <security@anthropic.com>" reaches the wire as Anthropic Security security@anthropic.com after angle-bracket sanitization, which mail clients render as a forged sender. Pass allowAddressLikeFromName: true to override for legitimate product names. SMTP itself still prevents address-level spoofing (the envelope From: is bound to your authenticated identity), and arbitrary display names without @ are still allowed (e.g. "CEO of Acme") — treat fromName like any other user-controllable string.

All send/reply/forward/save_draft tools accept an alternative markdownBody parameter (rendered to HTML via marked) — mutually exclusive with body+isHtml. sanitizeHtml applies after Markdown rendering.

🛡️ Outbound preview + self-only lock. send_email, reply_email, reply_all_email, and forward_email accept dryRun: true — it runs all validation and resolves the complete recipient set (To/CC/BCC, including the reply-all fan-out) and returns it without sending, leading with an [outbound:*] token and an explicit list of any external (non-self) recipients. Use it to confirm exactly who would receive the mail before a live call. For throwaway/QA accounts, set RESTRICT_OUTBOUND_TO_SELF=true (see Environment variables) to refuse any live send to a non-self recipient — preventing an agent from fanning real mail out to external addresses embedded in seed data. (Preview is caller-opt-in; the env lock is enforced server-side with no per-call override.)

send_email

Send an email using Proton Mail SMTP.

reply_email

Reply to a message with proper threading headers (In-Reply-To, References). Includes the quoted original message with attribution by default.

reply_all_email

Reply to all original recipients (sender + TO + CC), excluding the authenticated user. Same threading + quoting semantics as reply_email. Use this instead of reply_email + replyAll: true for clarity. Self-exclusion covers the whole recipient set including the primary To: replying-all to a message you sent reaches the original recipients rather than looping back to you.

forward_email

Forward a message to new recipients. Original attachments are carried forward by default. Unlike reply, a forward does not set In-Reply-To/References — it starts its own conversation and leaves the original message's \Answered flag untouched.

save_draft

Save an email as a draft without sending it. The draft is placed in the user's \Drafts special-use folder (resolved at runtime; falls back to literal Drafts if no annotation). Returns the draft UID when available.

ⓘ Destination changed in v1.0.0 — the folder parameter is gone. Previously callers could land a \Draft-flagged message in any folder, including INBOX, which was confusing for anyone scanning the mailbox.

Reading

list_folders

List all mailbox folders with message and unread counts. No parameters. Counts come from a cached IMAP STATUS that Proton Bridge can serve stale — for an exact count (e.g. before deleting or emptying a folder), use count_messages or folder_stats, which query the live mailbox. The output includes a footer reminding callers of this.

Non-selectable namespace containers (Proton's top-level Folders / Labels nodes, which hold nested mailboxes but can't store messages) are tagged (namespace — not a mailbox). Selectability is decided by positive evidence (a live message count, or a childless mailbox with a successful STATUS) overriding the raw \Noselect flag, because Proton Mail Bridge has been seen reporting populated labels with the flag set. The reading tools (list_messages, search_messages, count_messages, folder_stats) reject these containers with an actionable error instead of silently reporting them empty.

list_messages

List recent messages from a folder. Supports UID-based pagination.

Pagination caveat. The default date sort is paginated by a UID cursor (beforeUid). In folders where UID order disagrees with date order — All Mail, or any folder holding messages that were moved into it — page boundaries (and the internal 500-message scan cap) can skip or reorder messages relative to strict date order. For exact, skip-free paging, pass sortByUid: true (orders by UID = arrival order, newest first); for a precise date window, use search_messages with since/before. INBOX (append-only, UID ≈ date) is unaffected either way.

Snippet safety. includeSnippet (here and on search_messages) returns ~200 chars of raw, sender-controlled body per row. When snippets are present the response appends an untrusted-content banner; treat any text after the — separator on a row as data, never instructions — it's a prompt-injection surface for agents that triage by snippet. Use read_message (which fences the full body) when you need to act on body content.

read_message

Read a specific message by UID. Returns full headers, body, and attachment metadata. Prefers plain text; strips HTML tags from HTML-only messages. Body-part selection skips parts marked Content-Disposition: attachment, so a text/plain attachment sitting next to an HTML body is never returned as the body.

The body is always fenced in [BEGIN UNTRUSTED EMAIL BODY] / [END UNTRUSTED EMAIL BODY] markers. With preferHtml: true the body is the verbatim wire HTML (not run through the send-side sanitizer), so it can contain <script>, inline event handlers, javascript: URLs, frames, or remote <img> tracking beacons. When any of those are detected the response emits a [html:active-content] token before the body — do not render or execute that HTML; treat it strictly as data. (cid:/data: inline images aren't flagged.)

list_attachments

List attachment metadata (part numbers, filenames, types, sizes) for a message without downloading the body. Composes with download_attachment for bulk extraction. The reported size is the decoded file size (roughly what you get on save), estimated from the IMAP-encoded octet count — base64 parts are ~37% smaller decoded than their wire size. It's displayed with a leading ~ because it's approximate (±~2 bytes, not byte-exact — don't assert on it or pre-allocate buffers); the exact byte count comes from download_attachment, which reports the real decoded length.

download_attachment

Download an attachment by MIME part number. Use list_attachments or read_message first to see available parts. By default returns base64-encoded content inline. Bad part numbers produce an actionable error listing known parts.

When the ALLOW_FILE_DOWNLOAD_DIR env var is set, the optional saveTo parameter writes the decoded bytes to disk inside that allowlist root and returns the file path + size instead of base64 — avoids blowing the token budget on large attachments. Path safety: rejects absolute paths, .. traversal, and symlink escapes. If the configured directory doesn't exist, you get an actionable "create it first" error rather than a raw ENOENT.

ⓘ Pre-flight size guard. When called without saveTo, the guard compares the attachment's base64-encoded size (what the inline response actually costs) against a ~40 KB cap — roughly a 29 KB decoded file. Larger attachments throw upfront, since the inline base64 would overflow most MCP framework response caps; the error reports both the decoded and encoded sizes so they line up with the threshold. To download larger files, set ALLOW_FILE_DOWNLOAD_DIR in your client config and pass saveTo. For Claude Desktop, add to claude_desktop_config.json:

{
  "mcpServers": {
    "proton-mail": {
      "command": "node",
      "args": ["/path/to/proton-mail-mcp/build/index.js"],
      "env": {
        "ALLOW_FILE_DOWNLOAD_DIR": "/Users/you/proton-attachments"
      }
    }
  }
}

Then call download_attachment with saveTo: "report.pdf" (relative to that directory). The response returns the file path + byte count instead of inline base64.

⚠️ For an agent to read back what it saved, the same directory must also be mounted into the agent's workspace/file tools. ALLOW_FILE_DOWNLOAD_DIR only grants this server permission to write there — it does not grant the calling agent permission to read it. If the two don't overlap, the agent can save an attachment but not open it, making "download this attachment and tell me what's in it" a dead end. Point ALLOW_FILE_DOWNLOAD_DIR at a folder that's already connected to the agent's environment (e.g. a Claude Cowork directory) so the round-trip works end-to-end.

search_messages

Search messages by various criteria. Date filters use IMAP semantics: since is inclusive, before is exclusive.

ⓘ Timezone gotcha: IMAP SINCE / BEFORE compare each message's INTERNALDATE against the server's local-date interpretation of the YYYY-MM-DD value, not strict UTC. On Proton Mail Bridge this is typically the host's local timezone. A message timestamped 03:14 UTC on May 26 may still register as May 25 if the server's clock is west of UTC — pad the date range by a day if precision matters.

ⓘ For subject/body queries on freshly-sent mail, results may lag by 30–60 seconds (Proton's index updates asynchronously). The response surfaces a staleness footer pointing at list_messages or findByMessageId when applicable.

get_thread

Get all messages in a conversation thread by walking In-Reply-To and References headers. Returns messages sorted chronologically (oldest first).

Prefer messageId — Message-IDs are globally unique, so this sidesteps the UID-collision footgun (UIDs are per-folder in IMAP) and walks INBOX + Sent + All Mail by default to catch replies that span folders. (uid mode is single-folder and will silently undercount a cross-folder thread.) Output rows are tagged UID X @FolderName in both modes, and the response dedupes by Message-ID across mailbox copies — the same physical message appearing in INBOX and All Mail collapses into one row tagged (also in: All Mail) instead of double-counting the thread. A thread member that lives in a user folder (e.g. Folders/Development) and surfaces only via the All Mail virtual copy is rewritten to its real storage folder and UID, so the folder/uid pair each row reports is valid in a single-folder tool (move_message / delete_message) rather than an All Mail UID that would misfire.

Scope: reply chain only. This walks In-Reply-To/References, so it returns the reply chain. Forwards are not included — a forward doesn't reference the original (it starts its own conversation), so a forwarded copy of a message won't appear in that message's thread. A 1-result thread doesn't mean a bug when only forwards (not replies) exist.

Organizing

move_message

Move a message to a different folder. Returns the new UID in the destination folder when available (requires UIDPLUS server support).

delete_message

Delete a message. By default moves to Trash for safety (resolved via special-use annotation); set permanent=true to permanently expunge. Returns the new UID in Trash when available. Soft-deleting a message that is already in Trash is a no-op on the server; the tool detects this and returns an actionable error suggesting permanent: true rather than an opaque failure.

update_message_flags

Add or remove flags on a message. RFC 3501 system flags: \Seen (read), \Flagged (starred), \Answered, \Draft, \Deleted, \Recent. User-defined keywords without a backslash prefix are also accepted (alphanumeric + underscore, e.g. Important, Custom_Tag). Unknown \-prefixed names are rejected.

Post-STORE verify: the server's FETCH response is checked against the requested operation. Flags the server failed to apply (commonly user keywords silently dropped by Proton Mail Bridge) are reported in the response as no-op (not applied): ....

update_message_labels

Add or remove Proton labels on a message. Labels live under the Labels/ namespace and are additive — the message stays in its source folder while gaining or losing label tags.

• Add is implemented as IMAP COPY from the source folder to Labels/<name>. The source UID is unchanged.

• Remove locates the message in the label mailbox by its Message-ID header and messageDeletes that UID — removing only the label, not the underlying message.

Adds are strict: copying to a missing label throws Label not found: <path> (create it first with create_label). Removes are idempotent — removing a label that doesn't apply, or doesn't exist as a mailbox, is a silent no-op.

mark_all_read

Mark all unread messages in a folder as read. Optionally limit to messages older than a given date. Pass dryRun: true to preview the affected count without flipping any flags.

bulk_move

Move many messages in a single IMAP operation. Accepts either an explicit uids array or match criteria (XOR, not both). Supports dryRun: true to preview which UIDs would be affected without making changes — match-based dry-runs run the SEARCH results through a FETCH-based existence pass so the preview matches what the live operation will actually do (Proton Mail Bridge's SEARCH index lags FETCH for ~1–2s after a recent move/delete, and the preview would otherwise list phantom UIDs that have already left the folder). Reports notFound[] for UIDs the pre-check didn't see. Same dry-run accuracy applies to bulk_delete, bulk_update_flags, and bulk_update_labels.

bulk_delete

Delete many messages in a single IMAP operation. Same XOR uids/match input and dryRun support as bulk_move. Defaults to soft-delete via the resolved Trash path. A subject/body match appends a staleness warning — Proton's content SEARCH lags ~30–60s, so recent mail can be silently missed; prefer from:/date filters or explicit uids for destructive cleanup.

bulk_update_flags

Add or remove flags on many messages in a single IMAP operation. Same XOR uids/match input and dryRun support. Reports notApplied: string[] for flags the server silently dropped across every affected UID (e.g. Proton's user-keyword drop).

bulk_update_labels

Add or remove Proton labels on many messages in a single IMAP operation. Same XOR uids/match input and dryRun support as the other bulk tools. Adds are batched (one COPY of the joined UID range per label); removes walk each label mailbox by Message-ID. Reports notApplied: string[] for labels with no observed effect (e.g., a remove for a label none of the UIDs actually carried).

create_folder

Create a new mailbox folder. Idempotent — succeeds silently if the folder already exists. Restricted to the Folders/ namespace (e.g. Folders/Receipts); root-level paths are rejected with an actionable error. Labels/... paths are rejected with a redirect to the dedicated create_label tool. . and .. path segments are rejected — symmetric with delete_folder, so anything you can create here you can also clean up.

create_label

Create a new Proton label. Pass the bare label name; the Labels/ prefix is added internally. Idempotent. The response returns the full Labels/X path — copy that into update_message_labels.labelsToAdd (which requires the full path, not the bare name).

rename_folder

Rename an existing folder or label. Restricted to the Folders/ and Labels/ namespaces on both from and to so system mailboxes (INBOX, Sent, Trash, etc.) can't be renamed — without this guard, rename_folder(from: "INBOX", to: ...) would succeed against Proton Mail Bridge and relocate INBOX's contents. . and .. path segments are rejected on both ends. Cross-namespace renames are also rejected (Folders/X → Labels/Y and vice versa) with an actionable error pointing at bulk_move / update_message_labels for the right primitive. Missing-source errors are translated to an actionable message (post-failure status() probe so Proton's bare Command failed doesn't leak through).

delete_folder

Delete a folder or label container. Restricted to the Folders/ and Labels/ namespaces so system mailboxes (INBOX, Sent, Trash, etc.) cannot be removed.

ⓘ Path-segment guard relaxed in v1.0.0. delete_folder accepts ./.. segments (e.g. Folders/../Escape) — IMAP treats paths as opaque literal names with no parent-dir semantics, so the previous guard provided no security but blocked legitimate cleanup of adversarial paths created by other IMAP clients or older versions of this MCP. create_folder / rename_folder still reject those segments where keeping confusable paths out of existence is the point.

On Proton Mail this is not a destructive message operation:

• Deleting a Folders/... path relocates its contents into All Mail. The response reports the count — Its N message(s) were relocated to All Mail (not deleted). — so a bare "deleted" isn't mistaken for message destruction.

• Deleting a Labels/... path removes the label tag and leaves the underlying message untouched in its source folder. The response says The label was removed from N message(s); the messages themselves are unchanged.

• Cascading children: deleting a folder with nested sub-folders removes the whole subtree. The response lists the cascaded children explicitly so you don't lose track of what disappeared.

No confirm flag is required — the risk profile is metadata-only.

empty_folder

Permanently empty a folder via atomic UID EXPUNGE (client.messageDelete). Requires confirm: true. By default restricted to Trash and Junk to prevent accidents; set allowAnyFolder: true to target any folder. Pass dryRun: true to preview the count that would be deleted without touching any mail (no confirm required for a dry run).

⚠️ Not registered by default. Set ALLOW_EMPTY_FOLDER=true in the environment to opt in. Enabling is not recommended — Trash is the user's last line of defense against destructive agent actions. The web UI empties Trash in two clicks; the convenience of delegating that to an LLM rarely justifies the irreversibility. Leave it off unless you have a specific automation that needs it.

count_messages

Return a count of messages matching optional criteria, backed by IMAP SEARCH. No envelope fetch — just a number.

folder_stats

Return total/unread counts plus scanned-envelope aggregations: oldest message date, newest message date, and total message bytes. Response includes scanned and truncated fields for transparency.

top_senders

Return a sender frequency table over a configurable date range, sorted by message count descending. Collapses display-name variants of the same address. Each row carries a direction: "self"|"received" tag so callers scanning All Mail (which spans Sent) can tell outbound from inbound.

🛡️ Display names are attacker-controlled. Buckets are keyed by email address; the row label uses the most frequently observed display name for that address, so a single email with a spoofed From name (e.g. "Your Bank" <attacker@x>) can't poison the label for an address. The email address is always shown alongside the name — treat the name as untrusted and key any trust decision on the address.

⚠️ Breaking change in v1.0.0: excludeSelf now defaults to true. The authenticated user's own outgoing messages are dropped from the table unless you opt in with excludeSelf: false.

When the table comes back empty but envelopes were scanned, the response explains that excludeSelf: true filtered everything (the usual cause on a self-to-self or outbound-only folder) and points at excludeSelf: false — so an empty table isn't misread as "folder empty" or a tool failure.

move_thread

Move all messages in a thread to a destination folder. Identified by Message-ID. Per-folder by default; set acrossFolders: true to walk INBOX + Sent + All Mail. When the walk surfaces a thread member only via All Mail (e.g. the message actually lives in Folders/Archive), the server expands the search across user folders to find the real storage location before mutating — without that step the operation would no-op against All Mail under Proton's label model. Dry-runs include an acrossFolders scope hint when the default false is in effect.

delete_thread

Delete all messages in a thread. Per-folder by default; set acrossFolders: true for cross-folder walk.

flag_thread

Add or remove flags on all messages in a thread. Per-folder by default; set acrossFolders: true for cross-folder walk.

Inbox cleanup workflows

Move all newsletters from a sender to Archive

1. search_messages(folder: "INBOX", listId: "politics.substack.com", limit: 5) — confirm matches.

2. bulk_move(folder: "INBOX", match: { listId: "politics.substack.com" }, destination: "Archive", dryRun: true) — preview the affected UIDs.

3. bulk_move(folder: "INBOX", match: { listId: "politics.substack.com" }, destination: "Archive") — commit.

Identify and prune the noisiest senders

1. top_senders(folder: "INBOX", since: "2025-01-01") — frequency table.

2. count_messages(folder: "INBOX", match: { from: "noreply@noisy.com" }) — exact count.

3. bulk_delete(folder: "INBOX", match: { from: "noreply@noisy.com" }, permanent: false, dryRun: true) — preview.

4. bulk_delete(folder: "INBOX", match: { from: "noreply@noisy.com" }, permanent: false) — soft-delete to Trash.

5. (Optional, opt-in only) empty_folder(folder: "Trash", confirm: true) — permanent cleanup. Requires ALLOW_EMPTY_FOLDER=true in the environment; not recommended — the Proton web UI empties Trash in two clicks and that's safer than handing the capability to an agent.

Configuration

Environment Variables

SMTP (required):

IMAP (for read/search tools):

Other:

Proton Mail Bridge quirks

A few observable behaviors of Proton Mail Bridge that affect tool output. Documented here so agents and humans don't mis-diagnose them as tool bugs.

• All Mail is eventually consistent. Moving a message into Trash strips it from All Mail, but the All Mail listing may transiently still show the moved message for a short window (seconds to a minute). If you need authoritative state immediately after a move, query the destination folder directly.

• Messages moved into Trash may carry the \Recent flag. Bridge re-flags the moved copy as \Recent (the server-managed "new arrival" indicator from RFC 3501), which can cause downstream tools that treat \Recent as "unread" to display Trash items as unread. \Seen state is independent and unchanged by the move.

• SEARCH lags FETCH for content predicates. search_messages with subject / body filters may take 30–60 seconds to surface a freshly-sent message because Bridge's content index updates asynchronously. The tool response surfaces a footer on zero-result subject/body queries pointing at list_messages or Message-ID lookup. SEARCH on from / to / date is typically immediate.

• top_senders over All Mail includes Sent. Because All Mail spans Sent, scans there will count your own outgoing addresses unless you keep the default excludeSelf: true. Each row carries a direction tag (self/received) so the table is honest about which side of the conversation each sender represents.

• Proton's label model cascades moves between folders. When you move a message from INBOX to Trash, Proton also strips the All Mail label as a side-effect (All Mail excludes Trash). A subsequent bulk_* op against All Mail with the original UIDs will correctly report them as not-present-at-execute-time — the response wording calls this out explicitly so it's not mistaken for a tool failure.

Development

npm run build          # Compile TypeScript
npm run watch          # Compile in watch mode
npm run test           # Run tests
npm run test:watch     # Run tests in watch mode
npm run lint           # Lint with ESLint
npm run format         # Format with Prettier
npm run inspector      # Launch MCP inspector

Acknowledgments

Originally based on protonmail-mcp by amotivv, inc.

License

MIT -- see LICENSE for details.