Skip to main content
Glama
googlarz

Proton Mail Bridge MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

reply_all_email

Destructive

Reply to all original recipients of an email at once, including sender and all To/CC addresses, while preserving threading headers for group conversations.

Instructions

Immediately reply to all original recipients (sender + all To/CC addresses) of an existing email. Identical to reply_to_email with replyAll enabled. Use when the conversation involves multiple parties and all should receive the reply. Threading headers (In-Reply-To, References) are preserved. Requires PROTONMAIL_ALLOW_SEND.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoAdditional CC recipients, comma-separated.
bccNoAdditional BCC recipients, comma-separated.
bodyNoReply body to prepend (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 full reply-all fan-out 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.
includeQuoteNoAppend the quoted original message to the reply body.
markdownBodyNoReply body 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 reply text and before the quoted original. 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.

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 reply text and before the quoted original. Set false to send without it for this one message.",
+  "type": "boolean"
+}
  3. Addedv1.13.4

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, so the description doesn't need to restate that. It adds context: 'Immediately reply', threading headers preserved, requires PROTONMAIL_ALLOW_SEND, and notes it is identical to reply_to_email with replyAll enabled. These enrich understanding without contradicting annotations. Slight gap: doesn't mention irreversibility explicitly, but destructiveHint covers that.

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

Conciseness4/5

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

Two sentences, front-loaded with purpose and usage. The first sentence defines the action; the second adds usage and context. The phrase 'Identical to reply_to_email with replyAll enabled' is slightly redundant with the first sentence but serves as a quick cross-reference. No wasted words.

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 send tool with no output schema, the description covers the core behavior, required environment variable, threading preservation, and usage context. The many parameters are fully documented in the schema. It doesn't describe the return value, but that's expected for a send action. Adequate for the complexity.

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% – every parameter has a descriptive string. The description itself adds no new parameter semantics beyond the schema, and the reference to reply_to_email doesn't elaborate on parameters. Baseline of 3 applies since 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?

The description clearly states the action (reply to all original recipients) and distinguishes it from reply_to_email (via 'Identical to reply_to_email with replyAll enabled') and forward_email. It names the resource (existing email) and scope (sender + To/CC). An agent can immediately understand the tool's function and differentiate it from siblings.

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?

Provides explicit guidance: 'Use when the conversation involves multiple parties and all should receive the reply.' It also references the alternative tool reply_to_email, implying when not to use this one (when replyAll is not needed). This is clear and actionable.

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