proton-mcp

Overview Schema Source Related Servers Discussions Admin

Prepare a forward as a draft

forward_draft

Creates a draft forwarding an email, quoting the original below your text and preserving attachments, so you can review before sending.

Instructions

Writes a forward of a message as a draft. The original is quoted below the new text, and when it carries attachments the whole original message is attached as well, so nothing of it is lost. Nothing is sent. The body is plain text and markup is not interpreted. HTML written here is delivered as visible characters, so the recipient would read the tags rather than see formatting. Give a message its shape with line breaks, blank lines, indentation and plain lists, and write a link as the bare address so that what is read is what is followed. A message may instead be written as markup, in the html field, which is delivered as formatting rather than as visible tags. Give one or the other, not both: a message that carries markup has its plain text half dropped, so the half that was confirmed would never arrive. Permitted are headings, paragraphs, line breaks, rules, quotes, emphasis, lists, tables, links and images, with colour, font, alignment, spacing and borders. Anything else is refused rather than quietly removed, and the answer names what and why. Note that the preview page linked from the confirmation lists every address in the message in full, including the ones behind links and images, and every alt text, because those are what a recipient reads. The question in the client stays short and carries counts instead. Text is UTF-8 everywhere: subject, body and addresses. Write characters as the language actually spells them, including umlauts, accents, sharp s, quotation marks and any other non-ASCII character. Do not transliterate them away (no "ae" for "ä", no "ss" for "ß"): the subject is encoded for transport and decoded again on arrival, and the body carries its character set, both verified against the Bridge. A transliterated message is simply a message with the wrong words in it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "messageId": "<messageId>",
      "to": "<to>"
    },
    "name": "forward_draft"
  }
}

Input Schema

Name	Required	Description	Default
`to`	Yes	Who to forward it to.
`html`	No	Your part of the message as markup instead of plain text. The original is quoted below it either way. The quote keeps the original's own markup, character for character, minus what would reach out of it: style blocks, document-level elements, scripts and comments. A message this server would not itself compose can therefore still be replied to or forwarded, but its formatting travels along, and so does anything a link in it points at.
`text`	No	Anything to say above the forwarded message.
`mailbox`	No	The mailbox the original is in, if known.
`messageId`	Yes	The message id from a listing or a search, with or without angle brackets.
`markupLevel`	No	How much markup is permitted. "standard" covers ordinary formatted mail. "extended" permits every CSS property, including ones that can hide content, and makes the confirmation carry a warning telling the person to open the preview. Prefer "standard"; reach for "extended" only when asked for something that needs it, such as a button, which requires display:inline-block.	standard

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.11Nov 1, 2026

TDQS

A3.8/5.0

Behavior5/5

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

Annotations only give the safety profile (writable, non-destructive, non-idempotent); the description adds substantial context beyond that: the original is quoted with attachments preserved, nothing is sent, markup outside the permitted set is refused rather than silently stripped, the confirmation page exposes all addresses and alt text, and the subject/body are UTF-8 round-tripped against the Bridge. No contradiction with the annotations.

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

Conciseness2/5

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

The purpose is front-loaded, but the body is roughly 350 words of loosely chained prose with no headings or grouping, and several points are restated (refusal of unsupported markup, the character-set rule) across multiple sentences. Much of the encoding and transliteration material is useful but buried; a bulleted split between message composition, markup level, and encoding would have earned the space.

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?

No output schema exists, and the description does explain the response surface: a confirmation with a preview link listing full addresses and alt text, and an error answer that names what was refused and why. For a 6-param write tool with rich annotations this is close to complete, though it never states what identifier or handle the created draft returns for the subsequent send_draft call.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description contributes real constraints the schema does not: "Give one or the other, not both" for text vs html, and the consequence (the plain-text half would be dropped). The permitted-markup enumeration and transliteration warning also disambiguate the text/html fields' content expectations beyond what the parameter descriptions state.

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?

Opens with a specific verb and resource: "Writes a forward of a message as a draft", and immediately adds the key scope qualifier "Nothing is sent", which is what separates it from send_forward. It never names the siblings it is not (send_forward, create_draft, reply_draft), so the agent must infer the routing from attributes rather than an explicit statement.

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 implied rather than stated: the draft/no-send framing tells the agent this is the preview-then-send path, and the html/text exclusivity rule constrains invocation. But there is no explicit "use this when X, use send_forward instead when Y", and the relationship to update_draft or send_draft (how a draft becomes sent) is never mentioned.

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