Skip to main content
Glama
googlarz

Proton Mail Bridge MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

forward_email

Destructive

Forward an existing email directly to new recipients, keeping original attachments and adding an optional note. Use when you have an emailId and need to re-route the message without review.

Instructions

Immediately forward an existing email to new recipients, preserving original attachments and prepending an optional note. Use when you have an emailId and want to re-route the message without review. Prefer create_forward_draft to stage a forward for review first. Requires PROTONMAIL_ALLOW_SEND.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoCC recipients, comma-separated.
toYesForward recipient list, comma-separated.
bccNoBCC recipients, comma-separated.
bodyNoOptional message before the forwarded content (plain text).
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 recipients without sending.
isHtmlNoSend body as HTML (ignored when markdownBody is provided).
emailIdYesOriginal email id.
fromNameNoOptional display name for the From header.
confirmedNoSet to true to confirm this irreversible send when PROTONMAIL_CONFIRM_DESTRUCTIVE is enabled.
attachmentsNoAttachments with base64 encoded content.
markdownBodyNoOptional introductory note in Markdown. Rendered to HTML with body as plain-text fallback; takes precedence over body+isHtml.
sanitizeHtmlNoStrip scripts and remote image beacons from HTML before delivery. Defaults to true.
appendSignatureNoAppend PROTONMAIL_SIGNATURE (if configured) after your note and before the forwarded content. Set false to send without it for this one message.
attachmentPartsNoForward only specific MIME part numbers, e.g. ["2", "3.1"]. Mutually exclusive with includeAttachments:false.
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.
includeAttachmentsNoInclude original attachments in the forward.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields 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"
+}
    • 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"
+}
  2. Changed1 schema field changedv1.17.1
    • addedInput schema / properties / appendSignature
      Added value: +{
+  "default": true,
+  "description": "Append PROTONMAIL_SIGNATURE (if configured) after your note and before the forwarded content. Set false to send without it for this one message.",
+  "type": "boolean"
+}
  3. Changed9 schema fields changedv1.13.4
    • addedInput schema / properties / attachmentParts
      Added value: +{
+  "description": "Forward only specific MIME part numbers, e.g. [\"2\", \"3.1\"]. Mutually exclusive with includeAttachments:false.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / body / description
      Previous value: -"Optional message before the forwarded content."New value: +"Optional message before the forwarded content (plain text)."
    • 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 recipients without sending.",
+  "type": "boolean"
+}
    • addedInput schema / properties / fromName
      Added value: +{
+  "description": "Optional display name for the From header.",
+  "type": "string"
+}
    • addedInput schema / properties / includeAttachments
      Added value: +{
+  "default": true,
+  "description": "Include original attachments in the forward.",
+  "type": "boolean"
+}
    • changedInput schema / properties / isHtml / description
      Previous value: -"Send body as HTML."New value: +"Send body as HTML (ignored when markdownBody is provided)."
    • addedInput schema / properties / markdownBody
      Added value: +{
+  "description": "Optional introductory note in Markdown. 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 and remote image beacons from HTML before delivery. Defaults to true.",
+  "type": "boolean"
+}
  4. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

The destructiveHint annotation already signals risk, and the description adds useful context: it requires PROTONMAIL_ALLOW_SEND, preserves attachments, and acts without review. The word 'Immediately' is slightly overstated because undoWindowSeconds and PROTONMAIL_SEND_DELAY_SECONDS can delay actual delivery, but it still conveys the no-draft, direct-send behavior.

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?

The description is two dense sentences that front-load the core purpose, then add routing guidance and a prerequisite. Every clause earns its place with no repetition of schema content or filler.

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

Completeness4/5

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

For a 17-parameter destructive send tool, the description covers the key operational context: when to use it, what it preserves, the permission requirement, and the safer alternative. It does not mention confirmation flows or send-delay behavior, but those are already documented in the schema and annotations, so the gap is minor.

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 description coverage is 100%, so the parameters are already well documented. The description adds minimal extra semantics beyond 'original attachments' and 'optional note,' which maps to existing parameters but does not materially improve an agent's understanding of the 17 fields.

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?

The description names a specific action (immediately forward an existing email), specifies recipients, and states that attachments are preserved and an optional note is prepended. It also differentiates the tool from create_forward_draft, making the purpose unmistakable.

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?

It explicitly tells the agent when to use it ('when you have an emailId and want to re-route the message without review') and provides a clear alternative for the staged-review workflow ('Prefer create_forward_draft'). This is strong routing guidance beyond the schema.

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