protonmail-mcp-server

Overview Schema Source Related Servers Discussions Admin

Vidarebefordra mejl

forward_email

Destructive

Forward a ProtonMail email while preserving its original text, HTML, and attachments inline, with optional added body text, CC/BCC recipients, and extra files.

Instructions

Vidarebefordra ett e-post med originalets text, HTML-version och bilagor.

Sätter Fwd:-prefix. Originalet följer med inline under ett rubrikblock ("Forwarded message"), både som text och — om originalet har en sådan — som HTML. Alla bilagor, bifogade mejl och inbäddade bilder följer med.

Args: uid: UID för e-posten att vidarebefordra to: Mottagaradress(er) body: Valfri text att lägga till ovanför det vidarebefordrade meddelandet mailbox: Mappen som UID:t kom från (obligatorisk). UID:n gäller per mapp: samma UID i en annan mapp är ett annat mejl. Använd fältet mailbox från svaret av list_emails, search_emails eller get_email. cc: Kopia-adress(er) bcc: Hemlig kopia-adress(er) attachments: Ytterligare filer att bifoga, utöver originalets bilagor — ett filnamn eller en lista, inom bilagekatalogen (PROTONMAIL_ATTACHMENT_DIR). Högst 20 filer och 25 MB tillsammans.

Returns: True om mejlet skickades. Vägrar servern några av mottagarna kastas ett fel som anger vilka — skicka då inte om till alla.

Raises: ValueError: "Inget meddelande med UID … i …" när UID:t inte finns i mailbox (oftast ett UID från en annan mapp) — inget skickas.

Input Schema

Name	Required	Description	Default
`cc`	No
`to`	Yes
`bcc`	No
`uid`	Yes
`body`	No
`mailbox`	Yes
`attachments`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.4.0Oct 21, 2026

addedInput schema / properties / attachments

Added value: +{
+  "anyOf": [
+    {
+      "minLength": 1,
+      "type": "string"
+    },
+    {
+      "items": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "maxItems": 20,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Attachments"
+}

addedInput schema / properties / bcc

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Bcc"
+}

addedInput schema / properties / cc

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Cc"
+}

removedInput schema / properties / mailbox / default
```
Removed value: -"INBOX"
```
addedInput schema / properties / mailbox / maxLength
```
Added value: +255
```
addedInput schema / properties / mailbox / minLength
```
Added value: +1
```

changedInput schema / required

Previous value: -[
-  "uid",
-  "to"
-]New value: +[
+  "uid",
+  "to",
+  "mailbox"
+]

First observedv0.1.0Jul 31, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already flag the safety profile (destructiveHint=true, openWorldHint=true, idempotentHint=false), and the description adds real behavioral detail on top: the Fwd: prefix, inline original in both text and HTML, attachment carry-over rules, the 20-file / 25 MB limit and PROTONMAIL_ATTACHMENT_DIR constraint on extra attachments, the partial-recipient-refusal error and the advice not to resend to everyone, and the ValueError for an unknown UID. The one gap is that it never explains what makes this operation 'destructive' despite destructiveHint being true.

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?

Front-loaded with the one-line purpose, then cleanly separated Args / Returns / Raises sections, so an agent can scan it quickly. It is somewhat verbose — the HTML-vs-text narration and the Returns sentence ('True om mejlet skickades') partly restate what the output schema already provides — but nothing is genuinely wasted.

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 a 7-parameter mutation tool with a 0%-covered schema, the description supplies everything needed to call it correctly: parameter meanings, the per-folder UID trap, attachment limits, error semantics (which recipients failed, whether anything was sent) and the success return. The output schema covers return values, so the description's brief Returns note is sufficient rather than missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does: uid, to, cc, bcc and body are all described, and mailbox — the highest-risk parameter — gets an explicit warning that UIDs are per-folder and must be taken from the mailbox field returned by list_emails/search_emails/get_email. The attachments parameter is also qualified (extra files beyond the original's, filename or list, max 20 / 25 MB), which the schema does not convey.

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

Purpose4/5

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

States a concrete verb+resource (forward an email) and enumerates exactly what is carried over: original text, HTML version, attachments, attached emails and embedded images, plus the Fwd: prefix and inline 'Forwarded message' block. It is not, however, differentiated from the sibling tools that also emit mail (send_email, reply_to_email, create_forward_draft, send_draft), so an agent gets no help picking among them from this field alone.

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

Usage Guidelines3/5

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

Usage is only implied: it is clearly the tool for passing on an existing message, and the mailbox argument points the caller at list_emails/search_emails/get_email as the source of that value. There is no explicit statement of when to prefer this over send_email or create_forward_draft/send_draft, and no when-not condition.

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