Skip to main content
Glama
googlarz

Proton Mail Bridge MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

send_email

Destructive

Compose and send a new outbound email through Proton Bridge SMTP, with support for attachments, HTML, priority, and delayed cancelable sends. Includes dry-run validation for preview.

Instructions

Compose and send a new outbound email through Proton Bridge SMTP. Use for one-shot messages that need no review. Prefer create_draft when you want to save and review before sending, or reply_to_email when responding to an existing message. Fails if PROTONMAIL_ALLOW_SEND is false or if Bridge SMTP is unreachable. If PROTONMAIL_SEND_DELAY_SECONDS is set, this queues the send instead of sending immediately and returns a cancelable id — call cancel_send within the window to abort. Otherwise returns delivery confirmation immediately.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoCC recipient email addresses, comma-separated.
toYesRecipient email addresses, comma-separated.
bccNoBCC recipient email addresses, comma-separated.
bodyNoEmail body content (plain text). Required unless markdownBody is provided.
fromNoSend as this address instead of the Bridge login's default (e.g. an alias or additional address on the same Proton account). Proton accepts any address verified on the account; an address not on the account is rejected by Proton at send time.
dryRunNoPreview the full recipient set and validate without sending.
isHtmlNoWhether body should be sent as HTML (ignored when markdownBody is provided).
replyToNoOptional reply-to email address.
subjectYesEmail subject.
fromNameNoOptional display name for the From header (e.g. 'Alice'). Does not change the sending address.
priorityNoSMTP priority header.
confirmedNoSet to true to confirm this irreversible send when PROTONMAIL_CONFIRM_DESTRUCTIVE is enabled.
attachmentsNoAttachments with base64 encoded content.
markdownBodyNoEmail body in Markdown. When provided, rendered to HTML with body as plain-text fallback; takes precedence over body+isHtml.
sanitizeHtmlNoStrip scripts, event handlers, and remote image beacons from HTML before delivery. Defaults to true when body is HTML.
appendSignatureNoAppend PROTONMAIL_SIGNATURE (if configured) to the body. Set false to send without it for this one message.
undoWindowSecondsNoOverride PROTONMAIL_SEND_DELAY_SECONDS for this one send: queue it for this many seconds (cancelable via cancel_send) instead of the server's configured default. 0 sends immediately even if the server has a default window configured. Same caveat as the server default: only fires while this server process stays running.
requestReadReceiptNoRequest a read receipt (MDN) via a Disposition-Notification-To header. Most mail clients ask the recipient before honoring it — this is a request, not a guarantee.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.37
    • addedInput schema / properties / from
      Added value: +{
+  "description": "Send as this address instead of the Bridge login's default (e.g. an alias or additional address on the same Proton account). Proton accepts any address verified on the account; an address not on the account is rejected by Proton at send time.",
+  "type": "string"
+}
  2. Changed1 schema field changedv1.18.1
    • addedInput schema / properties / undoWindowSeconds
      Added value: +{
+  "description": "Override PROTONMAIL_SEND_DELAY_SECONDS for this one send: queue it for this many seconds (cancelable via cancel_send) instead of the server's configured default. 0 sends immediately even if the server has a default window configured. Same caveat as the server default: only fires while this server process stays running.",
+  "type": "number"
+}
  3. Changed2 schema fields changedv1.17.0
    • addedInput schema / properties / appendSignature
      Added value: +{
+  "default": true,
+  "description": "Append PROTONMAIL_SIGNATURE (if configured) to the body. Set false to send without it for this one message.",
+  "type": "boolean"
+}
    • addedInput schema / properties / requestReadReceipt
      Added value: +{
+  "default": false,
+  "description": "Request a read receipt (MDN) via a Disposition-Notification-To header. Most mail clients ask the recipient before honoring it — this is a request, not a guarantee.",
+  "type": "boolean"
+}
  4. Changed8 schema fields changedv1.13.4
    • changedInput schema / properties / body / description
      Previous value: -"Email body content."New value: +"Email body content (plain text). Required unless markdownBody is provided."
    • addedInput schema / properties / confirmed
      Added value: +{
+  "description": "Set to true to confirm this irreversible send when PROTONMAIL_CONFIRM_DESTRUCTIVE is enabled.",
+  "type": "boolean"
+}
    • addedInput schema / properties / dryRun
      Added value: +{
+  "default": false,
+  "description": "Preview the full recipient set and validate without sending.",
+  "type": "boolean"
+}
    • addedInput schema / properties / fromName
      Added value: +{
+  "description": "Optional display name for the From header (e.g. 'Alice'). Does not change the sending address.",
+  "type": "string"
+}
    • changedInput schema / properties / isHtml / description
      Previous value: -"Whether body should be sent as HTML."New value: +"Whether body should be sent as HTML (ignored when markdownBody is provided)."
    • addedInput schema / properties / markdownBody
      Added value: +{
+  "description": "Email body in Markdown. When provided, rendered to HTML with body as plain-text fallback; takes precedence over body+isHtml.",
+  "type": "string"
+}
    • addedInput schema / properties / sanitizeHtml
      Added value: +{
+  "default": true,
+  "description": "Strip scripts, event handlers, and remote image beacons from HTML before delivery. Defaults to true when body is HTML.",
+  "type": "boolean"
+}
    • changedInput schema / required
      Previous value: -[
-  "to",
-  "subject",
-  "body"
-]New value: +[
+  "to",
+  "subject"
+]
  5. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare destructiveHint=true, so the description carries the burden for operational behavior — and it delivers: two named failure conditions (PROTONMAIL_ALLOW_SEND false, Bridge SMTP unreachable), queued-vs-immediate send semantics driven by PROTONMAIL_SEND_DELAY_SECONDS, cancelability via cancel_send, and the return behavior in each case. This is precisely the kind of context that lets an agent predict side effects and handle errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, zero filler. The core action and primary purpose are front-loaded, usage routing comes second, and behavioral caveats (gating, delay, cancellation) come last. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 18-parameter destructive mutation with no output schema, the description covers everything operationally material: what it does, when to use alternatives, both failure modes, the delay/queue/cancel path, and the immediate-return path. The schema covers all parameter semantics, so nothing an agent needs to call this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline of 3 applies — the schema fully documents all 18 parameters, including the nuanced ones like markdownBody precedence and from-address verification. The description adds no parameter-level detail, but none is needed since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Compose and send a new outbound email through Proton Bridge SMTP') and distinguishes itself from siblings by naming create_draft and reply_to_email as alternatives. An agent can tell exactly what this tool does and how it differs without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it ('one-shot messages that need no review') and when not to, naming the exact alternative tools and the conditions that select them ('Prefer create_draft when you want to save and review before sending, or reply_to_email when responding to an existing message'). Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools