Skip to main content
Glama
proton-mcp

proton-mcp

by RndmJoker

Forward a message

send_forward
Destructive

Forwards a Proton Mail message to new recipients, quoting the original and carrying attachments, with confirmation before sending.

Instructions

Forwards a message and sends it. The original is quoted, and when it carries attachments the whole original travels along so nothing of it is lost. By default every send asks the user to confirm first, through the client, showing the sender, every recipient separated into To, Cc and Bcc, and the subject. It carries no part of the message itself and links to a page where the whole thing can be read as the recipient will see it, and a client that cannot show the question cannot send. The user can allow a tool to send without asking, within bounds they choose; the answer then says that it did. 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": "send_forward"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesWho to forward it to.
htmlNoYour 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.
textNoAnything to say above the forwarded message.
mailboxNoThe mailbox the original is in, if known.
messageIdYesThe message being forwarded.
markupLevelNoHow 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.

  1. Addedv0.4.11

TDQS

A3.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the default per-send confirmation through the client, the preview link and what it contains, that attachments travel with the original, that a client unable to render the question cannot send, and that supplying html drops the plain-text half. These are exactly the non-obvious side effects an agent needs before firing a destructive send.

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?

A single dense paragraph of roughly a dozen sentences in which the highest-stakes warning (text and html are mutually exclusive) is buried mid-paragraph. The encoding material runs long and ends on a rhetorical flourish ("a transliterated message is simply a message with the wrong words in it"), and there is no structuring by topic.

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 six-parameter destructive send with no output schema, the description covers confirmation, preview, attachment propagation, markup limits and encoding thoroughly. It only lightly covers what comes back ("the answer then says that it did") and never explains when mailbox is needed.

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; the description earns an extra point by stating the non-obvious mutual-exclusivity rule between text and html and its consequence, plus the markup subset permitted and the refusal behavior. Encoding rules for addresses and subject add further meaning not in the schema.

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?

"Forwards a message and sends it" names a specific verb and resource, and the phrase "and sends it" implicitly separates this from a draft-creating sibling. However, forward_draft and send_reply are never named, so an agent must infer the boundary itself.

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?

Guidance exists for parameters (prefer markupLevel "standard", use "extended" only when asked) and for choosing text vs html, but nothing says when to use this tool rather than forward_draft, send_reply or send_message. When-to-use is implied rather than stated.

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