Skip to main content
Glama
googlarz

Proton Mail Bridge MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

update_draft

Edit an existing draft's recipients, subject, body, or other fields before sending. Only provided fields change; omitted fields stay the same, then send or sync the updated draft.

Instructions

Update an existing locally saved draft's recipients, subject, body, or other fields. Use to edit a draft before sending. Only provided fields are updated — omitted fields retain their current values. After updating, call send_draft to send or sync_draft_to_remote to push to Proton Drafts. The response's attachments are metadata only (filename/contentType/size, no base64 content) even if the draft has attachments from a previous call — use get_draft if you need the actual attachment bytes back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoCC recipient email addresses, comma-separated.
toNoRecipient email addresses, comma-separated.
bccNoBCC recipient email addresses, comma-separated.
bodyNoDraft body. Replaces the WHOLE body — for a change to part of a long draft use bodyEdits instead, which costs a fraction of the tokens.
fromNoSend as this address instead of the Bridge login's default when the draft is sent (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.
notesNoOptional local note for the draft.
isHtmlNoWhether the body should be HTML.
draftIdYesDraft id returned by create_draft, list_drafts, or a create_*_draft call.
replyToNoOptional reply-to email address.
subjectNoDraft subject.
priorityNo
bodyEditsNoChange parts of the existing body without resending it: find/replace edits applied in order (use instead of body; not both). Each find must appear exactly once in the body (add surrounding text to make it unique, or set all:true), otherwise nothing is changed and the error says why. replace:'' deletes the text. Matches the stored body literally — for an HTML draft that means the HTML source. The response reports bodyEditsApplied (number of replacements).
attachmentsNoAttachments with base64 encoded content.
syncToRemoteNoWhether to sync the updated draft to the Proton Drafts mailbox when IMAP is available.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.1.37
    • changedInput schema / properties / body / description
      Previous value: -"Draft body."New value: +"Draft body. Replaces the WHOLE body — for a change to part of a long draft use bodyEdits instead, which costs a fraction of the tokens."
    • addedInput schema / properties / bodyEdits
      Added value: +{
+  "description": "Change parts of the existing body without resending it: find/replace edits applied in order (use instead of body; not both). Each find must appear exactly once in the body (add surrounding text to make it unique, or set all:true), otherwise nothing is changed and the error says why. replace:'' deletes the text. Matches the stored body literally — for an HTML draft that means the HTML source. The response reports bodyEditsApplied (number of replacements).",
+  "items": {
+    "properties": {
+      "all": {
+        "default": false,
+        "description": "Replace every occurrence instead of requiring exactly one.",
+        "type": "boolean"
+      },
+      "find": {
+        "description": "Exact text to find (non-empty).",
+        "type": "string"
+      },
+      "replace": {
+        "description": "Replacement text; '' deletes.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "find",
+      "replace"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / from
      Added value: +{
+  "description": "Send as this address instead of the Bridge login's default when the draft is sent (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. Addedv1.17.0
  3. Removedv1.13.11
  4. Changed1 schema field changedv0.1.2
    • addedInput schema / properties / draftId / description
      Added value: +"Draft id returned by create_draft, list_drafts, or a create_*_draft call."
  5. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With only destructiveHint=false in annotations, the description carries the burden of behavioral disclosure and does it well: it reveals partial-update semantics ('omitted fields retain their current values') and a non-obvious response gotcha (attachments returned as metadata-only, no base64, even when the draft has attachments — redirecting to get_draft for bytes). No contradiction with destructiveHint=false.

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?

Three sentences, front-loaded with purpose, then usage semantics, follow-up routing, and the response caveat. Each sentence earns its place and there is no filler, though it is slightly long; the density of genuinely useful information justifies the length.

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 14-parameter tool with no output schema, the description covers the essentials: purpose, partial-update behavior, follow-up tool routing, and the return-value caveat about attachments. It does not describe the full response shape, but with 93% schema coverage on inputs and the key return gotcha disclosed, little an agent needs to call it 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 93%, so the schema already documents nearly every parameter; the description's mention of 'recipients, subject, body' maps to existing schema fields without adding syntax or format details beyond it. The baseline 3 applies because the schema does the heavy lifting and the description adds little parameter-specific value.

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 opens with a specific verb-resource pair ('Update an existing locally saved draft') and enumerates the target fields (recipients, subject, body). It differentiates from siblings by marking the draft as 'locally saved' (vs. remote Proton Drafts) and explicitly naming follow-up tools send_draft and sync_draft_to_remote, so an agent can separate it from create_draft, get_draft, and delete_draft.

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

Usage Guidelines4/5

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

States when to use it ('Use to edit a draft before sending') and gives clear post-conditions by routing to send_draft (to send) and sync_draft_to_remote (to push to Proton Drafts). It does not explicitly state when NOT to use it versus create_draft or get_draft, but the local-vs-remote framing plus the named alternatives provide solid routing context.

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