Skip to main content
Glama
googlarz

Proton Mail Bridge MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

reply_to_email

Destructive

Send an immediate reply to an existing email with correct threading, using the email ID. Ideal for quick responses without drafting.

Instructions

Immediately send a reply to an existing email, threading it correctly via In-Reply-To and References headers. Use when you have an emailId and want to send the reply right away. Prefer create_reply_draft to save the reply for review first, or create_thread_reply_draft when replying from a threadId. Use reply_all_email to reply to all original recipients. Requires PROTONMAIL_ALLOW_SEND.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoAdditional CC recipients, comma-separated.
bccNoAdditional BCC recipients, comma-separated.
bodyYesReply 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 recipient set and threading headers without sending.
isHtmlNoSend body as HTML (ignored when markdownBody is provided).
emailIdYesOriginal email id.
fromNameNoOptional display name for the From header.
replyAllNoReply to all original recipients.
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.17.0
  4. Removedv1.13.11
  5. Changed8 schema fields changedv1.13.4
    • changedInput schema / properties / body / description
      Previous value: -"Reply body to prepend."New value: +"Reply body to prepend (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 recipient set and threading headers without sending.",
+  "type": "boolean"
+}
    • addedInput schema / properties / fromName
      Added value: +{
+  "description": "Optional display name for the From header.",
+  "type": "string"
+}
    • addedInput schema / properties / includeQuote
      Added value: +{
+  "default": true,
+  "description": "Append the quoted original message to the reply body.",
+  "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": "Reply body 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"
+}
  6. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare destructiveHint=true, so the irreversible nature is already disclosed. The description adds useful behavioral context: it sends immediately, requires PROTONMAIL_ALLOW_SEND, and correctly sets threading headers. This exceeds the baseline for annotation-covered tools.

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?

Two sentences with no redundancy. The primary purpose is front-loaded, and the usage guidance is compact yet complete. Every clause earns its place.

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 tool with many optional parameters, the description covers the core decision points (immediate send, permission requirement, threading) and routes to alternatives. The schema handles parameter details, and the annotation covers destructiveness, so the description is sufficiently complete.

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 all 16 parameters are already documented in the schema. The description adds minimal parameter-specific value—only mentioning emailId implicitly in the usage guidance. This matches the baseline of 3 for full schema coverage.

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 states a specific verb ('send'), resource ('reply to existing email'), and a distinctive behavior (threading via In-Reply-To and References headers). It explicitly names sibling alternatives, making the tool's unique role unambiguous.

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 you have an emailId and want to send the reply right away.' It also lists alternatives with conditions (create_reply_draft for review, create_thread_reply_draft for threadId, reply_all_email for all recipients), leaving no ambiguity about when to choose this tool.

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